tal:content="python:obj.getProperty('something','').decode('utf-8')"/>
> ...rather than:
>
>
>- suffer frequent but not necessarilly reproducible, content-dependent
>unicode errors
>
>
Exactly. Yesterday I was rewriting a form that was build via ZMI
(ZPT and PythonScripts) to Five product. I ecouncered same
problems as you.
> - suffer frequent but not necessarilly reproducible, content-dependent
> unicode errors
In my case, same code works on one machine but fails with
unicode-decode errors on the second one...
You need to be very very careful when writing something and even
test the code on few machines... :-/
Other thing. Adding a new object (that uses addform directive and
has 'title' field in it's schema - unicode!) to a folder (via ZMI), may
result in strange characters displayed instead of national
characters in other objects' titles or, in the worst case, Unicode-decode
error when you're clicking on that folder in ZMI (you have to use Undo
then because it's not possible to see the folder contents).
--
Maciej Wisniowski
From philipp at weitershausen.de Thu Jul 20 01:07:12 2006
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Thu, 20 Jul 2006 01:07:12 +0200
Subject: [z3-five] pythonproducts monkey patches
In-Reply-To: <44BE2C57.5070409@wcm-solutions.de>
References: <44BE2C57.5070409@wcm-solutions.de>
Message-ID: <44BEBB20.7060701@weitershausen.de>
yuppie wrote:
> I'm not sure which collector to use for Five issues so I decided to
> report this to the list:
Yeah, thanks.
> The monkey patching code used in Five 1.4 is not very robust.
We accept patches :). Seriously, we do, though this is Rocky's code so I
hope he'll have something to say about this.
> If
> setupPythonProducts is called twice _originalGetPath is set twice - the
> second time with the patched getPath. This leads to an infinite
> recursion because the patched getPath calls _originalGetPath.
This seems easy enough to reproduce in a test...
> The unit tests actually depend on the fact that test_externalmethods is
> usually run before test_registerPackage. If you change their order
> (AFAICS they are run in alphabetical order) you can see the problem.
No idea in what order tests are run. I think it might also change with
the endinanness of your platform, the size of your screen and the colour
of your underpants.
> I stumbled over this issue because I did run the Five tests together
> with tests that initialize Five.
Well, you're actually not supposed to do that. Five tests will clean up
after them nicely. Stuff that does installProduct('Five') will not.
These two collide.
The monkey patches, when tested, should clean up after themselves. ALL
code that operates on global registries or does monkey patching should
clean up after itself. If pythonproducts doesn't do that, it's a bug.
(Note that zope.testing has a very nice hook for providing cleanup
functions. We use this in various places in Five.)
Philipp
From rocky at serverzen.com Thu Jul 20 01:25:11 2006
From: rocky at serverzen.com (Rocky Burt)
Date: Wed, 19 Jul 2006 20:55:11 -0230
Subject: [z3-five] pythonproducts monkey patches
In-Reply-To: <44BEBB20.7060701@weitershausen.de>
References: <44BE2C57.5070409@wcm-solutions.de>
<44BEBB20.7060701@weitershausen.de>
Message-ID: <1153351505.13188.3.camel@localhost>
On Thu, 2006-20-07 at 01:07 +0200, Philipp von Weitershausen wrote:
> We accept patches :). Seriously, we do, though this is Rocky's code so I
> hope he'll have something to say about this.
+1
> > If
> > setupPythonProducts is called twice _originalGetPath is set twice - the
> > second time with the patched getPath. This leads to an infinite
> > recursion because the patched getPath calls _originalGetPath.
Right, good catch.
> The monkey patches, when tested, should clean up after themselves. ALL
> code that operates on global registries or does monkey patching should
> clean up after itself. If pythonproducts doesn't do that, it's a bug.
I believe it probably doesn't.
- Rocky
--
Rocky Burt
ServerZen Software -- http://www.serverzen.com
News About The Server (blog) -- http://www.serverzen.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://codespeak.net/pipermail/z3-five/attachments/20060719/f07ab6b2/attachment.pgp
From rnd at onego.ru Thu Jul 20 10:45:09 2006
From: rnd at onego.ru (Roman Susi)
Date: Thu, 20 Jul 2006 11:45:09 +0300
Subject: [z3-five] UTF-8, Zope 2.9.x and MSIE
Message-ID: <44BF4295.8080106@onego.ru>
Hi,
I have a problem using Zope 2.9.x
Products.Five.form ... EditView, AddView
- scandinavian letters (e.g. ?, ?) are erroneously stored in the object
as a byte representation of utf-8 instead of correct text. And this
happens only when browsing with MSIE. Also, there is no such problem
when handling forms without any fancy EditView, AddView (just in a
method), form enctype doesn't matter.
Here two POSTs by MSIE and Firefox:
Accept-Encoding: gzip, deflate
Accept-Language: ru
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, application/msword, */*
Cache-Control: no-cache
Connection: Keep-Alive
Content-Length: 1955
Content-Type: multipart/form-data;
boundary=---------------------------7d6271194014e
Cookie: tree-expansion="xyxx"; tree-expansion="xyxx"; __ginger_snap="xyxx"
Host: xyxx:9080
POST /xyxx/edit.html HTTP/1.1
Referer: http://xyxx.org:9080/xyxx/edit.html
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
CLR 1.1.4322)
-----------------------------7d6271194014e
Content-Disposition: form-data; name="field.description"
dfdfgdfgdfgdfg sdfsdf ............
-----------------------------7d6271194014e
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Accept-Encoding: gzip,deflate
Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Connection: keep-alive
Content-Length: 1916
Content-Type: multipart/form-data;
boundary=---------------------------41184676334
Cookie: tree-expansion="xyxx"; tree-expansion="xyxx"; __ginger_snap="xyxx"
Host: xyxx:9080
Keep-Alive: 300
POST /xyxx/edit.html HTTP/1.1
Referer: http://xyxx/xyxx/edit.html
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.0.4)
Gecko/20060508 Firefox/1.5.0.4
-----------------------------41184676334
Content-Disposition: form-data; name="field.description"
dfdfgdfgdfgdfg sdfsdf ............
-----------------------------41184676334
(dots are for nonASCII, encoding is utf8)
The only simingly relevant difference is
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
field issued by Firefox...
Publisher encoding is set to utf-8 in zope.conf.
If unicode string u contains broken data, then this small function
corrects the unicode string:
def fixMSIE(us):
return unicode(eval(repr(us)[1:]), 'utf8')
Something somewhere in Zope makes wrong assumption about encoding of the
data (or does double decoding or...?)... Any ideas how to prevent this
madness from happening? google search has not produced any meaningful
results.
Thanks!
Regards,
Roman
From y.2006_ at wcm-solutions.de Thu Jul 20 11:05:28 2006
From: y.2006_ at wcm-solutions.de (yuppie)
Date: Thu, 20 Jul 2006 11:05:28 +0200
Subject: [z3-five] pythonproducts monkey patches
In-Reply-To: <44BEBB20.7060701@weitershausen.de>
References: <44BE2C57.5070409@wcm-solutions.de>
<44BEBB20.7060701@weitershausen.de>
Message-ID: <44BF4758.5040301@wcm-solutions.de>
Hi Philipp!
Philipp von Weitershausen wrote:
> yuppie wrote:
>> The monkey patching code used in Five 1.4 is not very robust.
>
> We accept patches :). Seriously, we do, though this is Rocky's code so I
> hope he'll have something to say about this.
I know ;) But I usually don't fix bugs myself if they have a low
priority for me or if someone else checked in the broken code recently.
>> The unit tests actually depend on the fact that test_externalmethods is
>> usually run before test_registerPackage. If you change their order
>> (AFAICS they are run in alphabetical order) you can see the problem.
>
> No idea in what order tests are run. I think it might also change with
> the endinanness of your platform, the size of your screen and the colour
> of your underpants.
All I wanted to say is this:
- tests should never rely on the order in which they are called
- apparently this bug was never noticed because in all environments in
which these tests were run so far test_externalmethods was called before
test_registerPackage
- renaming 'test_registerPackage' to 'test_a' did work for me to enforce
a different order
>> I stumbled over this issue because I did run the Five tests together
>> with tests that initialize Five.
>
> Well, you're actually not supposed to do that. Five tests will clean up
> after them nicely. Stuff that does installProduct('Five') will not.
> These two collide.
Sometimes I run tests I didn't write myself ;)
So far the only issue was that installProduct('Five') doesn't make sure
the ZCML is loaded because it might have been cleaned up by other tests.
If you are aware of that they don't collide. setupPythonProducts is
initialized with initialize(), not with ZCML.
> The monkey patches, when tested, should clean up after themselves. ALL
> code that operates on global registries or does monkey patching should
> clean up after itself. If pythonproducts doesn't do that, it's a bug.
That's one part of the solution. AFAICS other parts of Five make also
sure they don't apply monkey patches twice. Either using __five_method__
or using some other bookkeeping. That makes things more robust.
Cheers,
Yuppie
From rnd at onego.ru Thu Jul 20 13:49:06 2006
From: rnd at onego.ru (Roman Susi)
Date: Thu, 20 Jul 2006 14:49:06 +0300
Subject: [z3-five] SOLVED Re: UTF-8, Zope 2.9.x and MSIE
In-Reply-To: <44BF4295.8080106@onego.ru>
References: <44BF4295.8080106@onego.ru>
Message-ID: <44BF6DB2.2090902@onego.ru>
hI!
It seems, this small piece of code solves the problem (of course, it
does mean that webapp doesn use anything except for utf8, which is my
case):
from Products.Five.form import EditView as EV, AddView as AV
class EditView(EV):
charsets = ("utf-8",)
def _setPageEncoding(self):
self.request.RESPONSE.setHeader(
'Content-Type', 'text/html; charset=utf-8')
class AddView(AV):
charsets = ("utf-8",)
def _setPageEncoding(self):
self.request.RESPONSE.setHeader(
'Content-Type', 'text/html; charset=utf-8')
Then every part of a project should import these mended view-classes and
not those from Five.
Thank you for hints which came in privite email!
Regards,
Roman
Roman Susi wrote:
> Hi,
>
> I have a problem using Zope 2.9.x
> Products.Five.form ... EditView, AddView
>
> - scandinavian letters (e.g. ?, ?) are erroneously stored in the object
> as a byte representation of utf-8 instead of correct text. And this
> happens only when browsing with MSIE. Also, there is no such problem
> when handling forms without any fancy EditView, AddView (just in a
> method), form enctype doesn't matter.
>
> Thanks!
>
> Regards,
> Roman
From philipp at weitershausen.de Thu Jul 20 14:22:18 2006
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Thu, 20 Jul 2006 14:22:18 +0200
Subject: [z3-five] pythonproducts monkey patches
In-Reply-To: <44BF4758.5040301@wcm-solutions.de>
References: <44BE2C57.5070409@wcm-solutions.de>
<44BEBB20.7060701@weitershausen.de>
<44BF4758.5040301@wcm-solutions.de>
Message-ID: <44BF757A.20009@weitershausen.de>
yuppie wrote:
>>> I stumbled over this issue because I did run the Five tests together
>>> with tests that initialize Five.
>>
>> Well, you're actually not supposed to do that. Five tests will clean up
>> after them nicely. Stuff that does installProduct('Five') will not.
>> These two collide.
>
> Sometimes I run tests I didn't write myself ;)
... like the whole friggin' Plone test suite which installProduct()s a
brazillion products?!?
> So far the only issue was that installProduct('Five') doesn't make sure
> the ZCML is loaded because it might have been cleaned up by other tests.
> If you are aware of that they don't collide. setupPythonProducts is
> initialized with initialize(), not with ZCML.
I consider installProduct() harmful in either way, because it happens at
test module import level, not at test setup or execution time. So, for
example, even if the test runner was only looking for test modules,
importing them to check whether they contain tests that match a certain
condition (e.g. regex), installProduct() would be executed.
installProduct() is evil.
>> The monkey patches, when tested, should clean up after themselves. ALL
>> code that operates on global registries or does monkey patching should
>> clean up after itself. If pythonproducts doesn't do that, it's a bug.
>
> That's one part of the solution. AFAICS other parts of Five make also
> sure they don't apply monkey patches twice. Either using __five_method__
> or using some other bookkeeping. That makes things more robust.
Yes, but it's not enough. Monkey patches must be undoable (and the code
doing monkey patches must provides hooks for undoign them) for tests.
Let's say you run a test that exercises the monkey patches and then
later, within the same test run, a test is run that doesn't expect the
monkey patches in place. It's likely that the second test might fail.
Proper test isolation is hard, I realize that. But zope.testing
infrastructure makes it bearable, I think.
Philipp
From rocky at serverzen.com Thu Jul 20 14:26:07 2006
From: rocky at serverzen.com (Rocky Burt)
Date: Thu, 20 Jul 2006 09:56:07 -0230
Subject: [z3-five] pythonproducts monkey patches
In-Reply-To: <44BE2C57.5070409@wcm-solutions.de>
References: <44BE2C57.5070409@wcm-solutions.de>
Message-ID: <1153398354.28391.4.camel@localhost>
On Wed, 2006-19-07 at 14:57 +0200, yuppie wrote:
> I'm not sure which collector to use for Five issues so I decided to
> report this to the list:
>
> The monkey patching code used in Five 1.4 is not very robust. If
> setupPythonProducts is called twice _originalGetPath is set twice - the
> second time with the patched getPath. This leads to an infinite
> recursion because the patched getPath calls _originalGetPath.
>
> The unit tests actually depend on the fact that test_externalmethods is
> usually run before test_registerPackage. If you change their order
> (AFAICS they are run in alphabetical order) you can see the problem.
>
> I stumbled over this issue because I did run the Five tests together
> with tests that initialize Five.
Thanks for pointing this out. I've just committed a fix for this that I
believe addresses your concerns.
r69226:
"Made the pythonproducts monkey patching more robust by checking to
ensure patches aren't reapplied and cleaning up after itself."
Regards,
Rocky
--
Rocky Burt
ServerZen Software -- http://www.serverzen.com
News About The Server (blog) -- http://www.serverzen.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://codespeak.net/pipermail/z3-five/attachments/20060720/c14ada5b/attachment.pgp
From maciej.wisniowski at coig.katowice.pl Thu Jul 20 14:37:02 2006
From: maciej.wisniowski at coig.katowice.pl (=?UTF-8?B?TWFjaWVqIFdpxZtuaW93c2tp?=)
Date: Thu, 20 Jul 2006 14:37:02 +0200
Subject: [z3-five] SOLVED Re: UTF-8, Zope 2.9.x and MSIE
In-Reply-To: <44BF6DB2.2090902@onego.ru>
References: <44BF4295.8080106@onego.ru> <44BF6DB2.2090902@onego.ru>
Message-ID: <44BF78EE.6050603@coig.katowice.pl>
>Thank you for hints which came in privite email!
>
>
>
Is this possible to put these hints on the list?
Have you read posts in
'unicodes and strings in Zope 2.9's ZPT with Zope 3's i18n' topic?
After reading this I think that changing encoding this way in
editform and addform isn't correct. These values should be unicode
not utf-8 encoded strings.
--
Maciej Wisniowski
From plone at kevinkal.com Thu Jul 20 14:53:46 2006
From: plone at kevinkal.com (kevin7kal)
Date: Thu, 20 Jul 2006 08:53:46 -0400
Subject: [z3-five] objects, security,etc
In-Reply-To: <44BE8BA6.8050102@kevinkal.com>
References: <44BD2996.3080507@kevinkal.com> <44BD3640.3020705@kevinkal.com> <44BE27C4.8030101@kevinkal.com> <44BE887F.9010000@kevinkal.com>
<44BE8BA6.8050102@kevinkal.com>
Message-ID: <44BF7CDA.20500@kevinkal.com>
Maybe opening a tgz is more of a hassle for some. So I will cut and
paste my code and hopefully someone can point out my errror.
I create a 'Zclass2' object through the zmi and try this 'Script(Python)'
MZ = context.Zclass2
#print MZ.attribute1b.method1()
print MZ.attribute1b
print MZ.attribute1a
return printed
if I uncomment line 2, it fails with unauthorized to access attribute
'attribute1b'
--------------configure.zcml----------------------
-------------------myClass.py-----------------------------------
class class1(object):
''' a simple class with some attributes and methods'''
attribute1 = 'attribute 1'
attribute2 = 'attribute 2'
def __init__(self):
'''simple init for the class'''
return
def method1(self):
'''simple method 1'''
print 'method1'
return
def method2(self):
''' simple method 2'''
print 'method2'
return
class class2(object):
''' a second simple class with some attributes and methods'''
attribute1a = 'attribute 1a'
atrribute2a = 'attribute 2a'
def __init__(self):
'''simple init for the class'''
return
def method1a(self):
'''simple method 1a'''
return(class1)
def method2a(self):
'''simple method 2a'''
return(class1.method1())
attribute1b = property(fget=method1a)
attribute2b = property(fget=method2a)
----------------------myZClass.py-------------------------
from zope.interface import implements
from zope.schema.fieldproperty import FieldProperty
from OFS.SimpleItem import Item, SimpleItem
from persistent import Persistent
import myClass
from interfaces import *
class Zclass2(SimpleItem,myClass.class2):
'''a simple zope class that inherits from my class'''
implements(Izclass2)
def __init__(self,tmpID='',tmpTITLE=''):
'''non empty docstring'''
return
--------------------interfaces.py----------------------------
from zope.interface import Interface
from zope.schema import Text,TextLine
class Izclass1(Interface):
'''marker interface'''
class Izclass2(Interface):
'''marker interface'''
Please-point me to the err in my ways :-)
Thanks!
From y.2006_ at wcm-solutions.de Thu Jul 20 15:22:26 2006
From: y.2006_ at wcm-solutions.de (yuppie)
Date: Thu, 20 Jul 2006 15:22:26 +0200
Subject: [z3-five] pythonproducts monkey patches
In-Reply-To: <1153398354.28391.4.camel@localhost>
References: <44BE2C57.5070409@wcm-solutions.de>
<1153398354.28391.4.camel@localhost>
Message-ID: <44BF8392.7020801@wcm-solutions.de>
Hi Rocky!
Rocky Burt wrote:
> Thanks for pointing this out. I've just committed a fix for this that I
> believe addresses your concerns.
>
> r69226:
> "Made the pythonproducts monkey patching more robust by checking to
> ensure patches aren't reapplied and cleaning up after itself."
Great! The fix looks good and works for me.
Just one remark: The alphabetical order hack was just meant as an easy
way to demonstrate that the tests did depend on a specific order. I
don't think it is a good idea to use this for testing. Just duplicating
the line
>>> pythonproducts.setupPythonProducts(app)
has the same effect and is a much more explicit way to test this. And
the cleanup can be tested at the end of the test as e.g. done in
test_registerclass.py.
BTW: I'm afraid there is an other issue with pythonproducts. Today I saw
the same traceback as reported here:
http://article.gmane.org/gmane.comp.web.zope.plone.user/55325
The problem went away after restarting Zope and I can't tell you how to
reproduce this but it smells like a pythonproducts bug.
Cheers,
Yuppie
From chris at simplistix.co.uk Fri Jul 21 16:57:37 2006
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 21 Jul 2006 15:57:37 +0100
Subject: [z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's
i18n
In-Reply-To: <44BE5265.6030801@simplistix.co.uk>
References: <44B3D5D1.2010603@simplistix.co.uk> <319e029f0607111029y6d87906avce6fad2ab2a5a0e1@mail.gmail.com> <44B3E3C0.3040806@simplistix.co.uk> <44B3F32F.2030002@simplistix.co.uk> <44B6B1A5.8050800@weitershausen.de>
<44BE5265.6030801@simplistix.co.uk>
Message-ID: <44C0EB61.1020206@simplistix.co.uk>
Chris Withers wrote:
> All of these suck a lot. Can we really do nothing better?
Well, I actually buckled and put a sitecustomize.py on the python path
that chanded the default codec from ascii to utf-8.
I feel comfortable enough doing that with this project because I _know_
we've taken a lot of care to make sure that everything that's stored is
stored utf-8 encoded.
If you're unlucky enough to have mixed encodings stored in strings,
paticularly in zodb or relational database, then you're basically fucked ;-)
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
From plone at kevinkal.com Sat Jul 22 18:55:25 2006
From: plone at kevinkal.com (kevin7kal)
Date: Sat, 22 Jul 2006 12:55:25 -0400
Subject: [z3-five] accessing object from a list constructed in __init__.py
Message-ID: <44C2587D.4030008@kevinkal.com>
I'm doing some work with Five and have an aquisition related issue.
first, zope is zope 2.9.3
The trouble is with accessing the attributes of objects stored in the
number property in class2.
accessing class1.number via class2.method1a is no problem, the problem
seems to stem from constructing a list of objects ala class2.__init__,
if I try to append obj.__of__ in attribute1a I recieve an error that I
can not pickle a wrapped class. Is there some other trick with
acquisition to be able to access the attributes of an object which is
stored in a list of object constructed in the __init__ function of a class?
--myClass.py
import Acquisition
class class1(Acquisition.Explicit):
''' a simple class with some attributes and methods'''
attribute1 = 'attribute 1'
attribute2 = 'attribute 2'
_number = ''
def __init__(self,number2):
'''simple init for the class'''
self._number=number2*3
def method1(self):
'''return a string methd1'''
mthd1 = 'methd1'
return mthd1
def method2(self):
''' return a string methd2'''
mthd2 = 'method2'
return mthd2
def _get_number(self):
return self._number
number = property(fget=_get_number)
class class2(object):
''' a second simple class with some attributes and methods'''
attribute1a = []
attribute2a = []
def __init__(self):
'''create a list of class1 objects in attribute1a'''
i=1
while i < 5:
obj = class1(i)
self.attribute1a.append(obj)
i=i+1
def method1a(self):
'''instantiate class1 as object and return object usable by zope'''
obj = class1(5)
return obj.__of__(self)
def method2a(self):
'''returns class1.method1()'''
c1m1 = class1.method1()
return c1m1
attribute1b = property(fget=method1a)
attribute2b = property(fget=method2a)
From maciej.wisniowski at coig.katowice.pl Sun Jul 23 13:01:47 2006
From: maciej.wisniowski at coig.katowice.pl (Maciej Wisniowski)
Date: Sun, 23 Jul 2006 13:01:47 +0200
Subject: [z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's
i18n
In-Reply-To: <44C0EB61.1020206@simplistix.co.uk>
References: <44B3D5D1.2010603@simplistix.co.uk> <319e029f0607111029y6d87906avce6fad2ab2a5a0e1@mail.gmail.com> <44B3E3C0.3040806@simplistix.co.uk> <44B3F32F.2030002@simplistix.co.uk> <44B6B1A5.8050800@weitershausen.de> <44BE5265.6030801@simplistix.co.uk>
<44C0EB61.1020206@simplistix.co.uk>
Message-ID: <44C3571B.5070801@coig.katowice.pl>
>Well, I actually buckled and put a sitecustomize.py on the python path
>that chanded the default codec from ascii to utf-8.
>
>
>
Is this possible to see that code? I'm very interested in it :)
And in general why is unicode object better than
utf-8 encoded string?
--
Maciej Wisniowski
From rnd at onego.ru Mon Jul 24 07:37:31 2006
From: rnd at onego.ru (Roman Susi)
Date: Mon, 24 Jul 2006 08:37:31 +0300
Subject: [z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's
i18n
In-Reply-To: <44B6B1A5.8050800@weitershausen.de>
References: <44B3D5D1.2010603@simplistix.co.uk> <319e029f0607111029y6d87906avce6fad2ab2a5a0e1@mail.gmail.com> <44B3E3C0.3040806@simplistix.co.uk> <44B3F32F.2030002@simplistix.co.uk>
<44B6B1A5.8050800@weitershausen.de>
Message-ID: <44C45C9B.1020108@onego.ru>
Hi!
Philipp von Weitershausen wrote:
> Chris Withers wrote:
>
>>Chris Withers wrote:
>>
>>>Where in the ZPT/publishing stack do the unicodes get encode to strings
>>>then?
>>
>>Answer: probably in the publisher somewhere.
>
>
> Yes. In an ideal case (read: Zope 3), the application returns text as
> unicode and never has to bother with strings. The publisher will
> negotiate the best encoding with the browser and send 8 bits over the wire.
We had the same problems too. And what makes things worse is that some
legacy pieces of software (in our case it was ZopeTree) assume str, no
Unicode. Even exportimport fails in our project due to the facts strings
are stored in Unicode! (Zope 2.9)
So, it is good advice "not to mix", but it is not always clear where
things are coming from in reality.
>>Since Zope 3's i18n stuff returns unicode, you need to be ultra careful
>>that the rest of your ZPT generates either 7-bit ascii or unicode.
>
>
> Right. Combining 8-bit strings and unicode can lead to terrible errors.
> I wish Python hadn't gone down that route of making strings and unicode
> objects compatible. Then it'd be crystal clear when you're doing
> something evil...
>
>
>>In my case, I was inserting the utf-8 encoded title of a document into a
>>generated navigator...
>
>
> I see. When in doubt, just make sure that anything ending up in a ZPT is
> unicode. Of course, ideally, those document titles would be stored not
> in UTF-8 but in unicode...
We use this util function to minimize the textual bloat explicit unicode
conversions bring:
def u(s, encoding="utf-8"):
"""Convert from UTF8 to Unicode (if needed)"""
try:
return unicode(s, encoding)
except TypeError: # Already Unicode?
return unicode(s)
>
> Philipp
Regards,
Roman
From rnd at onego.ru Mon Jul 24 07:48:11 2006
From: rnd at onego.ru (Roman Susi)
Date: Mon, 24 Jul 2006 08:48:11 +0300
Subject: [z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's
i18n
In-Reply-To: <44C3571B.5070801@coig.katowice.pl>
References: <44B3D5D1.2010603@simplistix.co.uk> <319e029f0607111029y6d87906avce6fad2ab2a5a0e1@mail.gmail.com> <44B3E3C0.3040806@simplistix.co.uk> <44B3F32F.2030002@simplistix.co.uk> <44B6B1A5.8050800@weitershausen.de> <44BE5265.6030801@simplistix.co.uk> <44C0EB61.1020206@simplistix.co.uk>
<44C3571B.5070801@coig.katowice.pl>
Message-ID: <44C45F1B.3030101@onego.ru>
Maciej Wisniowski wrote:
>>Well, I actually buckled and put a sitecustomize.py on the python path
>>that chanded the default codec from ascii to utf-8.
>>
>>
>>
>
> Is this possible to see that code? I'm very interested in it :)
I know people sometimes do it, but it makes code unportable and could
cause other subtle problems.
>
> And in general why is unicode object better than
> utf-8 encoded string?
Unicode object is more preferable because it is easier to process (that
is, you you do not just store text but apply regular expressions,
searches, calculate lengths, etc.). Of course, usual 1-byte encoding is
even more simpler to use but it is not suitable on international scale.
So, utf-8 encoded strings are convenient only as Unicode serialization:
when sending Unicode over network, when storing in byte-oriented layers
(like Unicode-unaware database or XML file).
Unicode is more fun also.
Regards,
Roman
From maciej.wisniowski at coig.katowice.pl Mon Jul 24 09:28:52 2006
From: maciej.wisniowski at coig.katowice.pl (=?UTF-8?B?TWFjaWVqIFdpxZtuaW93c2tp?=)
Date: Mon, 24 Jul 2006 09:28:52 +0200
Subject: [z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's
i18n
In-Reply-To: <44C45F1B.3030101@onego.ru>
References: <44B3D5D1.2010603@simplistix.co.uk> <319e029f0607111029y6d87906avce6fad2ab2a5a0e1@mail.gmail.com> <44B3E3C0.3040806@simplistix.co.uk> <44B3F32F.2030002@simplistix.co.uk> <44B6B1A5.8050800@weitershausen.de> <44BE5265.6030801@simplistix.co.uk> <44C0EB61.1020206@simplistix.co.uk>
<44C3571B.5070801@coig.katowice.pl> <44C45F1B.3030101@onego.ru>
Message-ID: <44C476B4.20209@coig.katowice.pl>
>>Is this possible to see that code? I'm very interested in it :)
>>
>>
>
>I know people sometimes do it, but it makes code unportable and could
>cause other subtle problems.
>
>
I've already found some examples of sitecustomize.py that
change defaultencoding.
We're using windows and linux so it may be unportable, but
I think it may be still helpful in some cases.
Maybe it should be a option in zope.conf that will allow to
change this behaviour. Firstly I though that
'zpublisher-default-encoding' or 'locale' will do the thing...
but, as you know, it doesn't.
>Unicode is more fun also.
>
>
But is more difficult especially for begineers and
especially in Zope2. It's a bit strange to write
strings with u'. I've never seen this in other languages.
So far it seems that we have to use functions like
yours:
def u(s, encoding="utf-8"):
"""Convert from UTF8 to Unicode (if needed)"""
...
for data stored in attributes and for data
retrieved from database and be careful to use
u'...' strings instead of '...'.
Any other clues for Five programmers? :)
--
Maciej Wisniowski
From rnd at onego.ru Mon Jul 24 10:03:54 2006
From: rnd at onego.ru (Roman Susi)
Date: Mon, 24 Jul 2006 11:03:54 +0300
Subject: [z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's
i18n
In-Reply-To: <44C476B4.20209@coig.katowice.pl>
References: <44B3D5D1.2010603@simplistix.co.uk> <319e029f0607111029y6d87906avce6fad2ab2a5a0e1@mail.gmail.com> <44B3E3C0.3040806@simplistix.co.uk> <44B3F32F.2030002@simplistix.co.uk> <44B6B1A5.8050800@weitershausen.de> <44BE5265.6030801@simplistix.co.uk> <44C0EB61.1020206@simplistix.co.uk>
<44C3571B.5070801@coig.katowice.pl> <44C45F1B.3030101@onego.ru>
<44C476B4.20209@coig.katowice.pl>
Message-ID: <44C47EEA.6060705@onego.ru>
Maciej Wi?niowski wrote:
>
>>> Is this possible to see that code? I'm very interested in it :)
>>>
>>
>>
>> I know people sometimes do it, but it makes code unportable and could
>> cause other subtle problems.
>>
>>
> I've already found some examples of sitecustomize.py that
> change defaultencoding.
> We're using windows and linux so it may be unportable, but
> I think it may be still helpful in some cases.
I do not mean portability in a sense of different OSes -- i mean
portability between sites.
For example, for the same reasons it is not good to use time.strftime()
to format your string for email, for example,
because its locale-aware and email messages use strict format for that
(there is
rfc822.formatdate and maybe some newer function to do it)
>
> Maybe it should be a option in zope.conf that will allow to
> change this behaviour. Firstly I though that
> 'zpublisher-default-encoding' or 'locale' will do the thing...
> but, as you know, it doesn't.
>
>> Unicode is more fun also.
>>
>>
> But is more difficult especially for begineers and
> especially in Zope2. It's a bit strange to write
> strings with u'. I've never seen this in other languages.
>
Python 3000 will change this. Everything will be Unicode.
Also, if you have a lot of text content, why not separate it from the code?
> So far it seems that we have to use functions like
> yours:
>
> def u(s, encoding="utf-8"):
> """Convert from UTF8 to Unicode (if needed)"""
> ...
>
>
> for data stored in attributes and for data
> retrieved from database and be careful to use
> u'...' strings instead of '...'.
Some databases (or at least their Zope adapters) are aware of unicode -
for example PostgreSQL.
>
>
> Any other clues for Five programmers? :)
>
try to do things and gather experience. There are no coherent top-down
guides (I mean guides which describe things from concepts to concretics),
only module-oriented documentation (source code, tests, books) and
problem-oriented cookbook-style docs for zope3... And I think it is very
important to
study those new concepts of Zope3 which are coming at theoretical level
and they dive into practical work.
Five is in flux in square, between Zope3 and Zope2...
Regards,
Roman Susi
From chris at simplistix.co.uk Mon Jul 24 14:15:27 2006
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 24 Jul 2006 13:15:27 +0100
Subject: [z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's
i18n
In-Reply-To: <44C45F1B.3030101@onego.ru>
References: <44B3D5D1.2010603@simplistix.co.uk> <319e029f0607111029y6d87906avce6fad2ab2a5a0e1@mail.gmail.com> <44B3E3C0.3040806@simplistix.co.uk> <44B3F32F.2030002@simplistix.co.uk> <44B6B1A5.8050800@weitershausen.de> <44BE5265.6030801@simplistix.co.uk> <44C0EB61.1020206@simplistix.co.uk> <44C3571B.5070801@coig.katowice.pl>
<44C45F1B.3030101@onego.ru>
Message-ID: <44C4B9DF.4000507@simplistix.co.uk>
Roman Susi wrote:
> Maciej Wisniowski wrote:
>>> Well, I actually buckled and put a sitecustomize.py on the python path
>>> that chanded the default codec from ascii to utf-8.
>>>
>> Is this possible to see that code? I'm very interested in it :)
>
> I know people sometimes do it, but it makes code unportable
How so? None of the code that could usefully be ported from this project
relies on this fact (it all just runs off unicode), but the project
specific code does, and I think that's a safe assumption to make, given
what I've already stated...
> and could
> cause other subtle problems.
Such as? (or is this just goat/chicken worship?)
>> And in general why is unicode object better than
>> utf-8 encoded string?
>
> Unicode object is more preferable because it is easier to process (that
> is, you you do not just store text but apply regular expressions,
> searches, calculate lengths, etc.). Of course, usual 1-byte encoding is
> even more simpler to use but it is not suitable on international scale.
>
> So, utf-8 encoded strings are convenient only as Unicode serialization:
> when sending Unicode over network, when storing in byte-oriented layers
> (like Unicode-unaware database or XML file).
...or more simply put, you don't get Unicode errors if everything is
Unicode, and that's a pretty big win for me ;-)
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
From chris at simplistix.co.uk Mon Jul 24 14:13:28 2006
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 24 Jul 2006 13:13:28 +0100
Subject: [z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's
i18n
In-Reply-To: <44C3571B.5070801@coig.katowice.pl>
References: <44B3D5D1.2010603@simplistix.co.uk> <319e029f0607111029y6d87906avce6fad2ab2a5a0e1@mail.gmail.com> <44B3E3C0.3040806@simplistix.co.uk> <44B3F32F.2030002@simplistix.co.uk> <44B6B1A5.8050800@weitershausen.de> <44BE5265.6030801@simplistix.co.uk>
<44C0EB61.1020206@simplistix.co.uk>
<44C3571B.5070801@coig.katowice.pl>
Message-ID: <44C4B968.5080403@simplistix.co.uk>
Maciej Wisniowski wrote:
>
>> Well, I actually buckled and put a sitecustomize.py on the python path
>> that chanded the default codec from ascii to utf-8.
>>
> Is this possible to see that code? I'm very interested in it :)
From memory, create a sitecustomize.py on your PYTHONPATH:
import sys
sys.setdefaultencoding('utf-8')
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
From rnd at onego.ru Mon Jul 24 20:48:08 2006
From: rnd at onego.ru (Roman Susi)
Date: Mon, 24 Jul 2006 21:48:08 +0300
Subject: [z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's
i18n
In-Reply-To: <44C4B9DF.4000507@simplistix.co.uk>
References: <44B3D5D1.2010603@simplistix.co.uk> <319e029f0607111029y6d87906avce6fad2ab2a5a0e1@mail.gmail.com> <44B3E3C0.3040806@simplistix.co.uk> <44B3F32F.2030002@simplistix.co.uk> <44B6B1A5.8050800@weitershausen.de> <44BE5265.6030801@simplistix.co.uk> <44C0EB61.1020206@simplistix.co.uk> <44C3571B.5070801@coig.katowice.pl>
<44C45F1B.3030101@onego.ru> <44C4B9DF.4000507@simplistix.co.uk>
Message-ID: <44C515E8.7010407@onego.ru>
Chris Withers wrote:
> Roman Susi wrote:
>
>> Maciej Wisniowski wrote:
>>
>>>> Well, I actually buckled and put a sitecustomize.py on the python
>>>> path that chanded the default codec from ascii to utf-8.
>>>>
>>> Is this possible to see that code? I'm very interested in it :)
>>
>>
>> I know people sometimes do it, but it makes code unportable
>
>
> How so? None of the code that could usefully be ported from this
> project relies on this fact (it all just runs off unicode), but the
> project specific code does, and I think that's a safe assumption to
> make, given what I've already stated...
http://blog.ianbicking.org/illusive-setdefaultencoding.html?version=1%3fversion%3d1
But perhaps my fears arent wellgrounded - I never used sitecustomize as
it somehow feels bad...
>> and could
>> cause other subtle problems.
>
>
> Such as? (or is this just goat/chicken worship?)
People more experienced than me warned against that (it was on the
Russian Python-Zope list
http://itconnection.ru/pipermail/zopyrus/2006-April/083160.html). Using
sitecustomize means it should be remembered somehow on each installation
and upgrade. If this is no problem - then it is no problem.
Roman
From optilude at gmx.net Tue Jul 25 02:43:56 2006
From: optilude at gmx.net (Martin Aspeli)
Date: Tue, 25 Jul 2006 01:43:56 +0100
Subject: [z3-five] Integration tests with Five and ZCML
Message-ID:
Hi,
We've known for some time that it's Bad? that PloneTestCase does:
ZopeTestCase.installProduct('Five')
I discovered that if I mix any tests using PloneTestCase (and this
statement, at module level) with any pure-Zope3 test that uses
zope.app.testing.placelesssetup.setUp (with or without a corresponding
.tearDown) I get strange and confusing errors even though the tests in
question run fine if the PloneTestCase tests are separated from the
Zope3-style ones.
Well, you told me so. But my question is, how *should* PloneTestCase be
behaving. Bear in mind that in this case we're really talking about
integration tests. We *want* PTC to load "all ZCML for all of Products/"
(or at least all other products registered with installProduct()). We'd
rather not require test authors to think about a dependency tree of ZCML
files and load them all. For unit tests that's good, but for integration
tests (which are sadly still the most prevalent and convenient in the
Zope2 world - too many objects to mock, too much reliance on things like
acquisition) we want to make sure the environment behaves as closely to
Zope2-on-startup as is reasonable.
We've been bemoaning this problem for a long time. I'd like to get it
out of the world once and for all. ;-)
Martin
From maciej.wisniowski at coig.katowice.pl Tue Jul 25 10:19:26 2006
From: maciej.wisniowski at coig.katowice.pl (=?ISO-8859-2?Q?Maciej_Wi=B6niowski?=)
Date: Tue, 25 Jul 2006 10:19:26 +0200
Subject: [z3-five] Question about skins usage
Message-ID: <44C5D40E.1000405@coig.katowice.pl>
Hi
I've written product that defines my skin (named Skintest) but as far as
I found I
can use this in two ways only:
1. by writing ++skin++Skintest/ in url
2. by defining my skin as defaultSkin with overrides.zcml
I based on Web Component Development with Zope3 from
Philipp von Weitershausen, althouht I'm using Zope 2.9.4 and
Five 1.4 now.
Say, I would like to have few skins used in few different products.
Is there a way to define which view uses which skin?
Or how should I define URLs in my application to take care
about skins? So far I'm using something like
'%s/@@some_view.html' % (context.absolute_url())
do I have to write:
'%s/++skin++Skintest/@@some_view.html' % (context.absolute_url())
or implement something as a skin chooser like:
'%s/%s/@@some_view.html' % (context.getCurrentSkin(),
context.absolute_url())
What is the preffered way of doing such things?
--
Maciej Wisniowski
From philipp at weitershausen.de Tue Jul 25 10:29:01 2006
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Tue, 25 Jul 2006 10:29:01 +0200
Subject: [z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's
i18n
In-Reply-To: <44C476B4.20209@coig.katowice.pl>
References: <44B3D5D1.2010603@simplistix.co.uk> <319e029f0607111029y6d87906avce6fad2ab2a5a0e1@mail.gmail.com> <44B3E3C0.3040806@simplistix.co.uk> <44B3F32F.2030002@simplistix.co.uk> <44B6B1A5.8050800@weitershausen.de> <44BE5265.6030801@simplistix.co.uk> <44C0EB61.1020206@simplistix.co.uk> <44C3571B.5070801@coig.katowice.pl>
<44C45F1B.3030101@onego.ru> <44C476B4.20209@coig.katowice.pl>
Message-ID: <44C5D64D.7000808@weitershausen.de>
Maciej Wi?niowski wrote:
>>> Is this possible to see that code? I'm very interested in it :)
>>>
>>>
>> I know people sometimes do it, but it makes code unportable and could
>> cause other subtle problems.
>>
>>
> I've already found some examples of sitecustomize.py that
> change defaultencoding.
> We're using windows and linux so it may be unportable, but
> I think it may be still helpful in some cases.
>
> Maybe it should be a option in zope.conf that will allow to
> change this behaviour. Firstly I though that
> 'zpublisher-default-encoding' or 'locale' will do the thing...
> but, as you know, it doesn't.
>
>> Unicode is more fun also.
>>
>>
> But is more difficult especially for begineers
It's pretty easy, I think. Most people just don't explain it well enough.
Unicode is an *abstraction*, like an image you see on your screen. An
image on your screen cannot be saved simply like that. You have to save
it in some sort of format, which means, in some way that arranges bytes.
There are several of such formats, e.g. PNG, JPG, etc. Some of them are
"lossy" because they cannot transfer the whole image information.
Same with unicode. A unicode object is a nice object-oriented
abstraction. It can hold any unicode "character". But, you cannot simply
save unicode to the filesystem or send it over the wire. You have to do
this in bytes, and again, a format (=encoding) tells you how to convert
unicode into such a format. Some of the are lossy (because they don't
support the whole Unicode range) and some of them aren't (e.g. UTF-*).
To make a long story short:
- In Python, we want to work with the abstraction. Working with
8bit-strings is like working with the byte representation of an image to
do image manipulation. That sucks
- When going to the filesystem or the HTTP client, we have to use some
encoding. We really only need to worry about the filesystem; talking to
the HTTP client is the ZPublisher's task. And, since the ZPublisher is a
Python component, we want to talk unicode to it.
The ZODB is also a Python component. Hence, we store unicode. SQL
database adapters are also Python components. They really SHOULD give us
unicode, not some 8bit encoded jibberish.
Now, I realize there's legacy data in the ZODB where 8bit strings are
stored. When you know this, you can explicitly deal with this. But don't
introduce legacy when writing new stuff...
> and especially in Zope2. It's a bit strange to write strings with u'.
> I've never seen this in other languages.
And I've never seen meaningful indention in other languages. What's your
point? You want to reject unicode because you don't like its syntax???
> So far it seems that we have to use functions like
> yours:
>
> def u(s, encoding="utf-8"):
> """Convert from UTF8 to Unicode (if needed)"""
> ...
Huh? Simply do some_unicode_string.encode('utf-8'). But, again, unless
you're actually writing stuff to the filesystem, I doubt you should ever
have to manually encode or decode stuff, even in Zope 2 (provided you
use certain helpers from Five).
> for data stored in attributes and for data retrieved from database
> and be careful to use u'...' strings instead of '...'.
Anything that contains human text should be unicode. That's a very
simple rule.
Philipp
From maciej.wisniowski at coig.katowice.pl Tue Jul 25 11:26:02 2006
From: maciej.wisniowski at coig.katowice.pl (=?UTF-8?B?TWFjaWVqIFdpxZtuaW93c2tp?=)
Date: Tue, 25 Jul 2006 11:26:02 +0200
Subject: [z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's
i18n
In-Reply-To: <44C5D64D.7000808@weitershausen.de>
References: <44B3D5D1.2010603@simplistix.co.uk> <319e029f0607111029y6d87906avce6fad2ab2a5a0e1@mail.gmail.com> <44B3E3C0.3040806@simplistix.co.uk> <44B3F32F.2030002@simplistix.co.uk> <44B6B1A5.8050800@weitershausen.de> <44BE5265.6030801@simplistix.co.uk> <44C0EB61.1020206@simplistix.co.uk> <44C3571B.5070801@coig.katowice.pl>
<44C45F1B.3030101@onego.ru> <44C476B4.20209@coig.katowice.pl>
<44C5D64D.7000808@weitershausen.de>
Message-ID: <44C5E3AA.9090509@coig.katowice.pl>
>It's pretty easy, I think. Most people just don't explain it well enough.
>
>
You're right, when starting with python it is rather difficult to find
out what and why
this unicode is. I understand it, but thanks for this nice explatation,
it will be helpful :)
>>and especially in Zope2. It's a bit strange to write strings with u'.
>>I've never seen this in other languages.
>>
>>
>
>And I've never seen meaningful indention in other languages. What's your
>point? You want to reject unicode because you don't like its syntax???
>
>
No! I'm not rejecting unicode. I simply don't like writing
u'...' :) I think it may be error prone and difficult for
newcomers to track down unicode decode errors that
appear because of forgetting about this.
But I understand why u'syntax is used now.
As Roman Susi said in other topic, in Python3000 everything
will be unicode, so I understand we'll have not to
use u'syntax, do we?
When I'm reading posts from me, Chris Withers, Roman Susi
and others I can say that unicode in Five isn't so easy in practice,
especially without good documentation, and clear rules such:
"Anything that contains human text should be unicode" :)
>Huh? Simply do some_unicode_string.encode('utf-8'). But, again, unless
>you're actually writing stuff to the filesystem, I doubt you should ever
>have to manually encode or decode stuff, even in Zope 2 (provided you
>use certain helpers from Five).
>
>
Yes you should'n have to encode or decode but, as you said before, only
if you
don't have to deal with legacy stuff, things that are setup via ZMI
(like attributes of folders etc.), database adapters that don't use
unicode etc.
I have all such things right now so the method from
Roman Susi that try: excepts: is nice for me.
I definitely agree we should move everything to unicode,
but it's not so easy.
If somebody has to write something new and knows the
rules then he'll possibly have no such problems...
until he forgets about u'...' somewhere ;)
--
Maciej Wisniowski
From chris at simplistix.co.uk Tue Jul 25 11:46:27 2006
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 25 Jul 2006 10:46:27 +0100
Subject: [z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's
i18n
In-Reply-To: <44C476B4.20209@coig.katowice.pl>
References: <44B3D5D1.2010603@simplistix.co.uk> <319e029f0607111029y6d87906avce6fad2ab2a5a0e1@mail.gmail.com> <44B3E3C0.3040806@simplistix.co.uk> <44B3F32F.2030002@simplistix.co.uk> <44B6B1A5.8050800@weitershausen.de> <44BE5265.6030801@simplistix.co.uk> <44C0EB61.1020206@simplistix.co.uk> <44C3571B.5070801@coig.katowice.pl>
<44C45F1B.3030101@onego.ru> <44C476B4.20209@coig.katowice.pl>
Message-ID: <44C5E873.2010804@simplistix.co.uk>
Maciej Wi?niowski wrote:
> I've already found some examples of sitecustomize.py that
> change defaultencoding.
> We're using windows and linux so it may be unportable, but
> I think it may be still helpful in some cases.
I don't think the OS has anything to do with this...
> Maybe it should be a option in zope.conf that will allow to
> change this behaviour.
nah, it needs to happen way before then, hence sitecustomize.py
>> Unicode is more fun also.
>>
> But is more difficult especially for begineers and
> especially in Zope2. It's a bit strange to write
> strings with u'. I've never seen this in other languages.
Yes, Python 3000 will fix this...
> for data stored in attributes and for data
> retrieved from database and be careful to use
> u'...' strings instead of '...'.
Well, that's only true for constants. Otherwise, you just need to make
sure you turn strings into unicodes as soon as possible...
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
From chris at simplistix.co.uk Tue Jul 25 11:50:58 2006
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 25 Jul 2006 10:50:58 +0100
Subject: [z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's
i18n
In-Reply-To: <44C515E8.7010407@onego.ru>
References: <44B3D5D1.2010603@simplistix.co.uk> <319e029f0607111029y6d87906avce6fad2ab2a5a0e1@mail.gmail.com> <44B3E3C0.3040806@simplistix.co.uk> <44B3F32F.2030002@simplistix.co.uk> <44B6B1A5.8050800@weitershausen.de> <44BE5265.6030801@simplistix.co.uk> <44C0EB61.1020206@simplistix.co.uk> <44C3571B.5070801@coig.katowice.pl>
<44C45F1B.3030101@onego.ru> <44C4B9DF.4000507@simplistix.co.uk>
<44C515E8.7010407@onego.ru>
Message-ID: <44C5E982.3000103@simplistix.co.uk>
Roman Susi wrote:
>
> http://blog.ianbicking.org/illusive-setdefaultencoding.html?version=1%3fversion%3d1
I don't really see the relevance of that thread...
> But perhaps my fears arent wellgrounded - I never used sitecustomize as
> it somehow feels bad...
Yeah, well, I for one am glad it's there :-)
> People more experienced than me warned against that (it was on the
> Russian Python-Zope list
> http://itconnection.ru/pipermail/zopyrus/2006-April/083160.html). Using
> sitecustomize means it should be remembered somehow on each installation
> and upgrade. If this is no problem - then it is no problem.
Well if you have a decent buildout process, which you _should_ (and I do
- all my instance's are completely svn'ed) then this isn't a problem...
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
From faassen at infrae.com Tue Jul 25 13:13:52 2006
From: faassen at infrae.com (Martijn Faassen)
Date: Tue, 25 Jul 2006 13:13:52 +0200
Subject: [z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's
i18n
In-Reply-To: <44BE5265.6030801@simplistix.co.uk>
References: <44B3D5D1.2010603@simplistix.co.uk> <319e029f0607111029y6d87906avce6fad2ab2a5a0e1@mail.gmail.com> <44B3E3C0.3040806@simplistix.co.uk> <44B3F32F.2030002@simplistix.co.uk> <44B6B1A5.8050800@weitershausen.de>
<44BE5265.6030801@simplistix.co.uk>
Message-ID: <44C5FCF0.90407@infrae.com>
Chris Withers wrote:
> Philipp von Weitershausen wrote:
>> Yes. In an ideal case (read: Zope 3), the application returns text as
>> unicode and never has to bother with strings. The publisher will
>> negotiate the best encoding with the browser and send 8 bits over the wire.
>
> Indeed.
>
>>> In my case, I was inserting the utf-8 encoded title of a document into a
>>> generated navigator...
>> I see. When in doubt, just make sure that anything ending up in a ZPT is
>> unicode. Of course, ideally, those document titles would be stored not
>> in UTF-8 but in unicode...
>
> Hurm, I see a world of pain for Zope 2 going forward :-/
It is a world of pain indeed - Infrae has been dealing with this world
of pain for years now as Silva *is* one of the few appications in Zope 2
that behaves well for unicode. PlacelessTranslationService, which has
extremely nasty workarounds to allow users to combine encoded strings
with unicode strings was hurting us, as it introduced subtle bugs in
previously well-behaved code.
What the right way should be for existing Zope 2 applications I do not
know.
For *new* Zope 2 applications, my strong recommendation would be to
store human-readable text as unicode, and if your text is stored
externally (file, rdb), to decode it into unicode as soon as possible
when it enters your application.
Regards,
Martijn
From faassen at infrae.com Tue Jul 25 13:14:52 2006
From: faassen at infrae.com (Martijn Faassen)
Date: Tue, 25 Jul 2006 13:14:52 +0200
Subject: [z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's
i18n
In-Reply-To: <44C0EB61.1020206@simplistix.co.uk>
References: <44B3D5D1.2010603@simplistix.co.uk> <319e029f0607111029y6d87906avce6fad2ab2a5a0e1@mail.gmail.com> <44B3E3C0.3040806@simplistix.co.uk> <44B3F32F.2030002@simplistix.co.uk> <44B6B1A5.8050800@weitershausen.de> <44BE5265.6030801@simplistix.co.uk>
<44C0EB61.1020206@simplistix.co.uk>
Message-ID: <44C5FD2C.7070505@infrae.com>
Chris Withers wrote:
> Chris Withers wrote:
>> All of these suck a lot. Can we really do nothing better?
>
> Well, I actually buckled and put a sitecustomize.py on the python path
> that chanded the default codec from ascii to utf-8.
>
> I feel comfortable enough doing that with this project because I _know_
> we've taken a lot of care to make sure that everything that's stored is
> stored utf-8 encoded.
>
> If you're unlucky enough to have mixed encodings stored in strings,
> paticularly in zodb or relational database, then you're basically fucked ;-)
This is an extremely dangerous option indeed, as it may break libraries
which depend on Python's behavior being differently.
Regards,
Martijn
From faassen at infrae.com Tue Jul 25 13:21:49 2006
From: faassen at infrae.com (Martijn Faassen)
Date: Tue, 25 Jul 2006 13:21:49 +0200
Subject: [z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's
i18n
In-Reply-To: <44C5E982.3000103@simplistix.co.uk>
References: <44B3D5D1.2010603@simplistix.co.uk> <319e029f0607111029y6d87906avce6fad2ab2a5a0e1@mail.gmail.com> <44B3E3C0.3040806@simplistix.co.uk> <44B3F32F.2030002@simplistix.co.uk> <44B6B1A5.8050800@weitershausen.de> <44BE5265.6030801@simplistix.co.uk> <44C0EB61.1020206@simplistix.co.uk> <44C3571B.5070801@coig.katowice.pl> <44C45F1B.3030101@onego.ru>
<44C4B9DF.4000507@simplistix.co.uk> <44C515E8.7010407@onego.ru>
<44C5E982.3000103@simplistix.co.uk>
Message-ID: <44C5FECD.4020802@infrae.com>
Chris Withers wrote:
> Roman Susi wrote:
>> http://blog.ianbicking.org/illusive-setdefaultencoding.html?version=1%3fversion%3d1
>
> I don't really see the relevance of that thread...
This is what I wrote about it a while back:
http://faassen.n--tree.net/blog/view/weblog/2005/08/02/0
Regards,
Martijn
From philipp at weitershausen.de Tue Jul 25 13:47:16 2006
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Tue, 25 Jul 2006 13:47:16 +0200
Subject: [z3-five] Question about skins usage
In-Reply-To: <44C5D40E.1000405@coig.katowice.pl>
References: <44C5D40E.1000405@coig.katowice.pl>
Message-ID: <44C604C4.8080809@weitershausen.de>
Maciej Wi?niowski wrote:
> Hi
>
> I've written product that defines my skin (named Skintest) but as far as
> I found I
> can use this in two ways only:
>
> 1. by writing ++skin++Skintest/ in url
> 2. by defining my skin as defaultSkin with overrides.zcml
3. wherever you want you can attach a skin to the request, e.g. during
traversal somewhere.
> I based on Web Component Development with Zope3 from
> Philipp von Weitershausen, althouht I'm using Zope 2.9.4 and
> Five 1.4 now.
>
> Say, I would like to have few skins used in few different products.
Why? The one-layer-per-product rule from the CMF is pretty stupid.
> Is there a way to define which view uses which skin?
Not really.
> Or how should I define URLs in my application to take care
> about skins?
Why do you need this at all? What's your use case? Let's start there and
see if several skins are actually necessary.
Philipp
From philipp at weitershausen.de Tue Jul 25 14:02:24 2006
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Tue, 25 Jul 2006 14:02:24 +0200
Subject: [z3-five] Integration tests with Five and ZCML
In-Reply-To:
References:
Message-ID: <44C60850.90001@weitershausen.de>
Martin Aspeli wrote:
> Hi,
>
> We've known for some time that it's Bad? that PloneTestCase does:
>
> ZopeTestCase.installProduct('Five')
>
> I discovered that if I mix any tests using PloneTestCase (and this
> statement, at module level) with any pure-Zope3 test that uses
> zope.app.testing.placelesssetup.setUp (with or without a corresponding
> .tearDown) I get strange and confusing errors even though the tests in
> question run fine if the PloneTestCase tests are separated from the
> Zope3-style ones.
Right. This is EXACTLY why the installProduct('Five') thing is bad. It
makes tests that care about (and expect) proper test clean up break,
because installProduct('Five') itself knows nothing about proper cleanup
and cannot do it.
> Well, you told me so. But my question is, how *should* PloneTestCase be
> behaving.
Well, IIRC, PTC is pretty much used for any test case in Plone-related
tests? I mean, how can you even *call* these things unit tests...
Anyways, if PTC is meant to handle integration tests only, and you want
PTC to load up Five's ZCML and all the ZCML of all the products there
are, then here's what you do:
def afterSetUp(self):
from Products.Five import zcml
zcml.load_site() # this loads site.zcml
def beforeTearDown(self):
zope.testing.cleanup.cleanUp()
Now, of course, this will sloooooow. It will load and tear down all ZCML
stuff for *each* test. A better way would be to use a layer:
class FiveIntegrationTestLayer(object):
@classmethod
def setUp(cls):
from Products.Five import zcml
zcml.load_site() # this loads site.zcml
@classmethod
def tearDown(cls):
zope.testing.cleanup.cleanUp()
And PTC would simply do:
class PloneTestCase(ZopeTestCase):
layer = FiveIntegrationTestLayer
...
Note that neither PTC nor any test that derives from PTC should register
new components or even tear down anything (e.g. using
zope.testing.cleanup). THe idea with layers is that the layer does the
setup and tear down of test fixtures ONCE.
Perhaps we should add FiveIntegrationTestLayer to Five. Even better, we
should convert ZopeTestCase to use layers as well,
FiveIntegrationTestLayer just being one of those layers. I've been
meaning to do that for some time now
(http://www.z3lab.org/sections/blogs/philipp-weitershausen/2006_03_10_death-to-zopetestcase),
just haven't gotten around to do it... too busy dealing with Zope bugs
at EuroPython...
Philipp
From maciej.wisniowski at coig.katowice.pl Tue Jul 25 14:05:13 2006
From: maciej.wisniowski at coig.katowice.pl (=?UTF-8?B?TWFjaWVqIFdpxZtuaW93c2tp?=)
Date: Tue, 25 Jul 2006 14:05:13 +0200
Subject: [z3-five] Question about skins usage
In-Reply-To: <44C604C4.8080809@weitershausen.de>
References: <44C5D40E.1000405@coig.katowice.pl>
<44C604C4.8080809@weitershausen.de>
Message-ID: <44C608F9.7040607@coig.katowice.pl>
>>1. by writing ++skin++Skintest/ in url
>>2. by defining my skin as defaultSkin with overrides.zcml
>>
>>
>
>3. wherever you want you can attach a skin to the request, e.g. during
>traversal somewhere.
>
>
What do you mean by attaching skin to the request? Isn't it point 1?
>
>Why do you need this at all? What's your use case? Let's start there and
>see if several skins are actually necessary.
>
>
I'm just wondering about. My use case is that I'll have several
applications
and much more products in one Zope instance.
It seems to be possible to need something different in skin somewhere,
but as I said it is now just wondering about. That's why I'm
asking about how it should be done :)
So you mean that using overrides.zcml is preffered way?
--
Maciej Wisniowski
From philipp at weitershausen.de Tue Jul 25 14:12:28 2006
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Tue, 25 Jul 2006 14:12:28 +0200
Subject: [z3-five] Question about skins usage
In-Reply-To: <44C608F9.7040607@coig.katowice.pl>
References: <44C5D40E.1000405@coig.katowice.pl>
<44C604C4.8080809@weitershausen.de>
<44C608F9.7040607@coig.katowice.pl>
Message-ID: <44C60AAC.7040102@weitershausen.de>
Maciej Wi?niowski wrote:
>
>>> 1. by writing ++skin++Skintest/ in url
>>> 2. by defining my skin as defaultSkin with overrides.zcml
>>>
>>
>> 3. wherever you want you can attach a skin to the request, e.g. during
>> traversal somewhere.
>>
>>
> What do you mean by attaching skin to the request? Isn't it point 1?
Point 1 is just one spelling of changing a skin during traversal; it
could also be "invisible", e.g:
www.car-shop.com # default skin used
www.car-shop.com/usedcars # different skin because different shop
In this case, a traversal hook in "usedcars" changed the skin.
>> Why do you need this at all? What's your use case? Let's start there and
>> see if several skins are actually necessary.
>>
>>
> I'm just wondering about. My use case is that I'll have several
> applications and much more products in one Zope instance.
Let's drop the term "products", I never get the right kind of
connotation when it's used.
So, you have several applications in a Zope instance. That's indeed a
use case for having different skins. Each application probably wants its
own skin.
The question is, how will these different applications be reachable?
Will they get different domains? Then you can use rewrite rules:
www.car-shop.com -> http://localhost:8080/++skin++CarShop/carshop
www.usedcars.com -> http://localhost:8080/++skin++UsedCars/usedcars
If they are part of the same domain, use traversal hooks as described
above (www.car-shop.com vs. www.car-shop.com/usecars).
Philipp
From maciej.wisniowski at coig.katowice.pl Tue Jul 25 15:08:41 2006
From: maciej.wisniowski at coig.katowice.pl (=?UTF-8?B?TWFjaWVqIFdpxZtuaW93c2tp?=)
Date: Tue, 25 Jul 2006 15:08:41 +0200
Subject: [z3-five] Question about skins usage
In-Reply-To: <44C60AAC.7040102@weitershausen.de>
References: <44C5D40E.1000405@coig.katowice.pl>
<44C604C4.8080809@weitershausen.de>
<44C608F9.7040607@coig.katowice.pl>
<44C60AAC.7040102@weitershausen.de>
Message-ID: <44C617D9.2080402@coig.katowice.pl>
>Will they get different domains? Then you can use rewrite rules:
>
> www.car-shop.com -> http://localhost:8080/++skin++CarShop/carshop
> www.usedcars.com -> http://localhost:8080/++skin++UsedCars/usedcars
>
>If they are part of the same domain, use traversal hooks as described
>above (www.car-shop.com vs. www.car-shop.com/usecars).
>
>
We have many environments for our applications (developement, testing,
learning etc.)
so I think traversal hooks are better choice. I've never played with
them but
seems that I have to add something like:
def __before_publishing_traverse__(self, object, REQUEST):
""" Pre-traversal hook.
"""
# check if there is no skin already and
# add/modify a skin to REQUEST['TraversalRequestNameStack'] or
REQUEST.path
I'll look for more examples of this. Thanks.
--
Maciej Wisniowski
From philipp at weitershausen.de Tue Jul 25 15:23:09 2006
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Tue, 25 Jul 2006 15:23:09 +0200
Subject: [z3-five] Question about skins usage
In-Reply-To: <44C617D9.2080402@coig.katowice.pl>
References: <44C5D40E.1000405@coig.katowice.pl>
<44C604C4.8080809@weitershausen.de>
<44C608F9.7040607@coig.katowice.pl>
<44C60AAC.7040102@weitershausen.de>
<44C617D9.2080402@coig.katowice.pl>
Message-ID: <44C61B3D.1090709@weitershausen.de>
Maciej Wi?niowski wrote:
>
>> Will they get different domains? Then you can use rewrite rules:
>>
>> www.car-shop.com -> http://localhost:8080/++skin++CarShop/carshop
>> www.usedcars.com -> http://localhost:8080/++skin++UsedCars/usedcars
>>
>> If they are part of the same domain, use traversal hooks as described
>> above (www.car-shop.com vs. www.car-shop.com/usecars).
>>
>>
> We have many environments for our applications (developement, testing,
> learning etc.)
> so I think traversal hooks are better choice. I've never played with
> them but
> seems that I have to add something like:
>
> def __before_publishing_traverse__(self, object, REQUEST):
> """ Pre-traversal hook.
> """
> # check if there is no skin already and
> # add/modify a skin to REQUEST['TraversalRequestNameStack'] or
> REQUEST.path
Shrug! Don't mess with the traversal name stack. Simply use
IMySkin.providedBy(request) for checking whether the request has your
skin and zope.app.publisher.browser.applySkin(request, IMySkin) for
applying the skin to the request.
Remember: Skins are just interfaces (that provide ISkin).
Philipp
From maciej.wisniowski at coig.katowice.pl Tue Jul 25 15:28:58 2006
From: maciej.wisniowski at coig.katowice.pl (=?UTF-8?B?TWFjaWVqIFdpxZtuaW93c2tp?=)
Date: Tue, 25 Jul 2006 15:28:58 +0200
Subject: [z3-five] Question about skins usage
In-Reply-To: <44C61B3D.1090709@weitershausen.de>
References: <44C5D40E.1000405@coig.katowice.pl>
<44C604C4.8080809@weitershausen.de>
<44C608F9.7040607@coig.katowice.pl>
<44C60AAC.7040102@weitershausen.de>
<44C617D9.2080402@coig.katowice.pl>
<44C61B3D.1090709@weitershausen.de>
Message-ID: <44C61C9A.2040900@coig.katowice.pl>
Philipp von Weitershausen napisa?(a):
>Shrug! Don't mess with the traversal name stack. Simply use
>IMySkin.providedBy(request) for checking whether the request has your
>skin and zope.app.publisher.browser.applySkin(request, IMySkin) for
>applying the skin to the request.
>
>Remember: Skins are just interfaces (that provide ISkin).
>
>
>
Yes, looks much better :) Thanks again for your help and explanations!
--
Maciej Wisniowski
From pw_lists at slinkp.com Tue Jul 25 16:21:52 2006
From: pw_lists at slinkp.com (Paul Winkler)
Date: Tue, 25 Jul 2006 10:21:52 -0400
Subject: [z3-five] unicodes and strings in Zope 2.9's ZPT with Zope 3's
i18n
In-Reply-To: <44C5D64D.7000808@weitershausen.de>
References: <319e029f0607111029y6d87906avce6fad2ab2a5a0e1@mail.gmail.com>
<44B3E3C0.3040806@simplistix.co.uk>
<44B3F32F.2030002@simplistix.co.uk>
<44B6B1A5.8050800@weitershausen.de>
<44BE5265.6030801@simplistix.co.uk>
<44C0EB61.1020206@simplistix.co.uk>
<44C3571B.5070801@coig.katowice.pl> <44C45F1B.3030101@onego.ru>
<44C476B4.20209@coig.katowice.pl>
<44C5D64D.7000808@weitershausen.de>
Message-ID: <20060725142152.GA9857@slinkp.com>
On Tue, Jul 25, 2006 at 10:29:01AM +0200, Philipp von Weitershausen wrote:
> Maciej Wi??niowski wrote:
> > But is more difficult especially for begineers
>
> It's pretty easy, I think. Most people just don't explain it well enough.
Recommended reading:
http://www.joelonsoftware.com/articles/Unicode.html
--
Paul Winkler
http://www.slinkp.com
From regebro at gmail.com Tue Jul 25 16:22:00 2006
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 25 Jul 2006 16:22:00 +0200
Subject: [z3-five] Deprecating the old local site support
Message-ID: <319e029f0607250722v43fd6401u40e756052586d438@mail.gmail.com>
In Five 1.3 we introduced local site support. In Five 1.5 it gets
obsolete with the new site suport in zope.component. So, I'm gonna
deprecate it.
Because the number of people using this is low, and the new support is
better, and the old one is messier than the new one, and you can't use
both at the same time, I think it would be good if we have a short
deprecation period for this, and deprecate it already for 2.11.
Silence = agreement. :)
Opinions, questions?
--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
From pw_lists at slinkp.com Tue Jul 25 16:25:34 2006
From: pw_lists at slinkp.com (Paul Winkler)
Date: Tue, 25 Jul 2006 10:25:34 -0400
Subject: [z3-five] Question about skins usage
In-Reply-To: <44C604C4.8080809@weitershausen.de>
References: <44C5D40E.1000405@coig.katowice.pl>
<44C604C4.8080809@weitershausen.de>
Message-ID: <20060725142534.GB9857@slinkp.com>
On Tue, Jul 25, 2006 at 01:47:16PM +0200, Philipp von Weitershausen wrote:
> Why? The one-layer-per-product rule from the CMF is pretty stupid.
Which rule is that? My old CMF code frequently used multiple layers.
--
Paul Winkler
http://www.slinkp.com
From tseaver at palladion.com Tue Jul 25 18:00:49 2006
From: tseaver at palladion.com (Tres Seaver)
Date: Tue, 25 Jul 2006 12:00:49 -0400
Subject: [z3-five] Question about skins usage
In-Reply-To: <20060725142534.GB9857@slinkp.com>
References: <44C5D40E.1000405@coig.katowice.pl> <44C604C4.8080809@weitershausen.de>
<20060725142534.GB9857@slinkp.com>
Message-ID: <44C64031.9030908@palladion.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul Winkler wrote:
> On Tue, Jul 25, 2006 at 01:47:16PM +0200, Philipp von Weitershausen wrote:
>> Why? The one-layer-per-product rule from the CMF is pretty stupid.
>
> Which rule is that? My old CMF code frequently used multiple layers.
Hmmm, maybe Philipp doesn't really believe in layers? The original
point of layering was to allow reuse-with-override; later, the layers
became a way to organize "related" skin objects on disk. If you aren't
trying for those goals, then layers are definitely overhead you don't need.
Tres.
- --
===================================================================
Tres Seaver +1 202-558-7113 tseaver at palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFExkAx+gerLs4ltQ4RAjYbAJ9JaCEa6jxPKJqbNk+6Tc2M2MrSNwCeIpOh
lEj/mihuT0Uz0uTkchmppBE=
=BOr+
-----END PGP SIGNATURE-----
From y.2006_ at wcm-solutions.de Tue Jul 25 23:02:10 2006
From: y.2006_ at wcm-solutions.de (yuppie)
Date: Tue, 25 Jul 2006 23:02:10 +0200
Subject: [z3-five] SVN: Products.Five/branches/1.4/ Backported the
traversal order changes from zope 2.10
In-Reply-To: <20060713234801.BEB892032C8@mail.zope.org>
References: <20060713234801.BEB892032C8@mail.zope.org>
Message-ID: <44C686D2.2050600@wcm-solutions.de>
Hi!
Alec Mitchell wrote:
> Log message for revision 69121:
> Backported the traversal order changes from zope 2.10
There's a bug in that change. HEAD requests (and I guess also other
FTP/WebDAV requests) trigger this error:
ERROR Zope.SiteErrorLog http://www.example.org/mySite/virtual_hosting//
Traceback (innermost last):
Module ZPublisher.Publish, line 106, in publish
Module ZPublisher.BaseRequest, line 325, in traverse
Module webdav.NullResource, line 66, in __bobo_traverse__
NotFound: The requested resource was not found.
The VirtualHostMonster adds 'virtual_hosting//' to the URL (don't ask me
why). 'virtual_hosting' has to be acquired, but now a NullResource is
created instead.
Cheers,
Yuppie
From philipp at weitershausen.de Wed Jul 26 01:25:05 2006
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Wed, 26 Jul 2006 01:25:05 +0200
Subject: [z3-five] Question about skins usage
In-Reply-To: <44C64031.9030908@palladion.com>