2009/4/27 Chris McDonough <chr...@plope.com>:
> On 4/27/09 3:27 PM, Laurence Rowe wrote:
>> Martin Aspeli wrote:
>>> Laurence Rowe wrote:
>>>> Martin Aspeli wrote:
>>>>> Hi,
>>>>> First - a quick question: can we treat __name__ and id/getId()/_setId()
>>>>> as the same, always? OFS.SimpleItem has some support for letting id and
>>>>> name be the same, but the link is lost once both __name__ and id are
>>>>> set. Why isn't __name__ just a property that reflects self.id ?
>>>> I would prefer this to be the other way around -- getId() /  _setId()
>>>> should operate on __name__. It will be easier to drop OFS support in the
>>>> future if pickles store the real __name__ and __parent__ attributes. We
>>>> will presumably require a migration now anyway to add __parent__
>>>> pointers.
>>> It kind of already does that if 'id' isn't set. But when 'id' is set,
>>> they diverge.
>>> Also note that according to ILocation, __name__ is a TextLine, which
>>> implies unicode. unicode ids are a no-no in Zope 2.
>> I doubt it would be all that difficult to change the publisher to handle
>> unicode path segments.
> This would be the only sane thing to do if Zope was being created today.
> It's a lot saner to store Unicode object identifiers than string ones, and
> if you've got that it's a no-brainer to use Unicode path segments too.  But
> if you did one and not the other, it would be a worthless change.

My point here is that if we modify the publisher then maybe we can
start storing unicode __name__ attributes. Unicode container keys work
just fine now so long as they contain only ascii characters.

>>> The current solution I've put into dexterity is to let __name__ be a
>>> property that gets and sets id, but assumes its value is unicode. It'll
>>> fail if the unicode string can't be encoded to ASCII, though.
> That's certainly keeping with the spirit of the default "bad identifier"
> regex in OFS, but it does feel a little weird to need to never use
> high-order characters in ids (even if you did need to make them utf-8
> encoded).  I had to work around this for one very large application that
> wanted to use Zope as a filesystem storage and it was no fun at all (in
> fact, it would have been sanest to not use Zope for that).
>> This is what I'm worried about. If new code uses __name__ instead, then
>> it opens up the possibility to share ZODB content between Plone and
>> lightweight systems like repoze.bfg, as well as making it easier for
>> Plone to migrate to a cleaner content model. Plone has been around for
>> eight years now, I sincerely hope we are not still stuck on
>> OFS.SimpleItem for another eight years!
> I wouldn't worry much about trying to preserve compatibility between Zope 2
> and Zope 3/bfg at this level; it's highly unlikely that *any* Plone content
> object will work out of the box on any system other than Zope2 (or at least
> without a large chunk of Zope2 sitting around) due to abuses of things like
> "self.REQUEST" in Archetypes.  But I could be wrong.

You don't have to write Archetypes to use Plone though. Tools like
plone.app.content allow you to write sane, lightweight content types
with zope.schema today. You need to bring in a lot of baggage in your
base classes for things to be compatible with the CMF layer, but on
the storage layer at least things are starting to look fairly sane.
The acquisition changes in Zope 2.12 give us the possibility of
writing clean new code without having to rewrite everything at once.

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to