[Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS

[Chris McDonough]

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.

>> 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.

- C