[Framework-Team] Re: five.intid and object_implements index in Plone 3

whit d.w.morriss at gmail.com
Wed Jan 10 17:56:40 UTC 2007


Martin Aspeli wrote:
> Hi Whit,
>
> On 1/10/07, whit <d.w.morriss at gmail.com> wrote:
>> Martin Aspeli wrote:
>> > Hi guys,
>> >
>> > I'm toying with the idea of introducing five.intid as a dependency for
>> > Plone 3. Whit is responsible for this creation, so I'd like this input
>> > as well, but from discussions with him it seems quite useful.
>> >
>> > - It can be combined with Zope 3's catalog implementation
>> > - It can act as a generic reference catalog
>> s/reference catalog/uid catalog/
>>
>> it is a catalog of references(keyreference object to be exact), but to
>> create an content object -> content object reference system ala AT
>> reference lite, we would need to whip up a bit more(though not too 
>> much).
>
> Oh, yes, true. Well, a content object could potentially store a list
> of int ids its referencing, could it it not?
>
> Are int ids stable when objects move? Are modified?
>
> What about export/import?
they should be stable for both iirc. (if not, events should be able to 
maintain this)
>
>> > - We (I) could simpilfy plone.app.redirector a little bit by using it
>> > instead of a custom path storage (well, the storage would still need
>> > to be there to remember where things used to be, but it would be a bit
>> > more standards-based)
>> my brain is tickled but I can't remember why....
>
> :-)
>
> Just because I stole your code and concepts doesn't mean I can't take
> all the credit. ;)
/me laughs.

you deserve the credit ;)

I should remember the code better. I'm just glad someone salvaged it...
>
>> > - We could use intids in more generic places like that fabled
>> > selection widget. That is, we don't have to rely on context.UID().
>> >
>> this is a biggee.  In wicked, which hopefully soon will do all of it's
>> "relational" behavior internally, I've moved to only accessing uid via
>> an interface(IUID, a string or integer).  This opens up the ability to
>> say, make wicked links to AT content and listen content(done w/ plone
>> schemas).
>
> Yeah, that's my biggest win as well. Plus, it standarises us on what
> Zope 3 is using (more or less).
>
>> > - Add a subscriber for Products.CMFCore.IContentish, so that it takes
>> > care of all content
>> +1 to using IContentish, or maybe even constraining the interface more.
>> I discovered a ton of headaches as tried binding the subscriber from
>> IPersistent on inwards;  Plone and CMF do alot of ugly things with
>> persistence in site creation; intid is based on an object having an oid
>> and is subscribed to object create, therefore depends on fairly normal
>> ZODB behavior or you get ugly lowlevel errors.
>
> Right. I would've thought IContentish was safe, but we obviously need 
> to test.
>
>> > - Does it work well with portal_factory?
>> seems to work ok... I would like to see more investigation.
>
> Cool. portal_factory basically clones objects in funny ways, so ids
> may change between the in-factory and out-of-factory objects. Still,
> that ought to be ok.
>
what do we currently depend on portal_factory for? any possibility we 
could move to a fate style addforms by 3.5?(different topic....)
>> > - Does it give any noticable overhead (looks OK to me)?
>> as long as the subscriber are reasonably constrained.
>
> My thought too.
>
>> > - Is it using Zope 2.10 or Zope 2.9's local component registrations
>> > (should be easy to fix up anyway)?
>> I wrote it against 2.9 so it's probably using that utility reg routine.
>
> Believe so. Anyway, doing it in 2.10 is easier :)
>
>> my main concern is getting five.intid hammered on and probably at this
>> early stage, not piling too many irreversible dependencies upon it.
>>
>> my reasoning: Much of what is scary to me about this code adapting intid
>> to zope2 is what made it so nice for mfaasen writing it in zope3.  It
>> works at what ends up in Plone being a very low level and during
>> development, when things broke, you couldn't even create a plone
>> site(plone site creation alerted my to a myriad of possible issues with
>> keyreferences and the myriad of things you can do with a
>> transaction).    This got fire tested because during it's development I
>> was working with multiple other developers who just wanted to work on
>> site ui(was a real headache on a couple of occasions).
>>
>> I had to work very hard to get keyreferences and acquisition to play
>> nice.   Due to the tight relationship with the persistence mechanism,
>> when things do go wrong, you are often looking at errors upon
>> transaction commit rather than in the code that is causing the error.
>>
>> so that is my caveat emptor.  wiggy informed me that the cheeseshop link
>> for five.intid is broken. I'll try to fix this up, but otherwhise, just
>> do an svn pull for most current version.
>
> So how tested/stable would you say it is? Did you hammer it in the
> real world, or do you think there are problems you don't know how to
> resolve or areas which are largely untested?
>
real world == real world development situations but not run in 
production(tagger is waiting for some ui love before it debuts on 
openplans). 

I would like to have more eyes on it; I think it's safe to move ahead 
though I wouldn't wait any later in the game to do so(in this 
release).   Basically, my point is proceed with caution and vigilance.

-w
-------------- next part --------------
A non-text attachment was scrubbed...
Name: whit.vcf
Type: text/x-vcard
Size: 291 bytes
Desc: not available
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20070110/a270cf6d/attachment.vcf>


More information about the Framework-Team mailing list