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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )