Hi Whit,
On 1/10/07, whit <[EMAIL PROTECTED]> 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?
> - 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. ;)
> - 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.
> - 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?
Martin
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
