Re: Reference Engine Componentization

howdy philip! just getting back to this. thanks for your input ;)

Philipp von Weitershausen wrote:
> whit wrote:
> 
>>sorry for the cross post, but I know there are a number of other
>>reference engines out there and I would like to get input as we look
>>at moving the AT ref engine being a component.
>>
>>here is a rough list of steps:
>>
>>1) move current storage of references to use IAnnotations for new
>>content / reference classes. Create a layer of indirection, making
>>reference storage a configurable option.
>>
>>2) refactor UID storage to use IAnnotations
> 
> 
> I don't think neither references nor UID capabilities have to do with
> annotations. In fact, Zope 3 doesn't use annotations for either one:

noted...currently, in AT, references are stored in an annotation pattern 
(actually as a Folder stored as an attr on the holding object).  The 
reimplementation requires some sort of persistent storage, and the 
reference objects aren't content so storing them as using IAnnotation 
seemed logical.

Currently, references are very contentish. some sort of persistence 
mechanism will be required, though the behavior on a reference can be 
abstracted out through adapters, so what the object is created from 
matters less.

But they have to go somewhere...any suggestions?


> - UID capabilities: Zope 3 has the intid utility which allows one to
> assign any object a unique integer id. This should be adopted for Zope 2
> and I think it would be fairly easy to do wrt persistent objects (as the
> ZODB is the same)

The AT uid is suppose to be a UUID, thus enabling content migration from 
system to system.  would it be possible to combine the uuid into a 
derivative of the intid utility?


> - Extrinsic references: AT lets us add extrinsic references of one
> object to another. A Zope 3 implementation for this kind of references
> based on key references (zope.app.keyreference) is available in the ZC
> sandbox repository: http://svn.zope.org/Sandbox/zc/extrinsicreference/.
> With a bit of cleaning up and some docs I think it could very well
> become zope.extrinsicreference for Zope 3.3.

I will study up on this...it would be nice to at least drag AT closer to 
whatever will define the paradigm in z3.


> Something that the CMF and Plone *could* start using annotations for is
> metadata such as DublinCore. In particular, every time some code is
> accessing DublinCore metadata, it should be changed to adapt to
> ICMFDublinCore first, even if that adaption might be a null-adaption for
> now (meaning, for now CMF content types always provide ICMFDublinCore).
> Note that ICMFDublinCore, despite its name, is part of Zope 3.

I'll add this to the list.   Currently, AT's contract with dublincore is 
'ExtensibleMetadata', basically a prepended schema that implements it's 
own storage.

>>3) implement IReferenceable to replace Referenceable mixin, implement
>>   IReference to coexist with Reference class
> 
> 
> By "implementing" IReference / IReferenceable you probably don't mean
> the interface itself (there isn't much to implement) but the necessary
> adapter logic that lets us get rid of the mix-in. I think the default
> adapter should use the reference "engine" based on key references.

That's what I have in mind.  Fufilling the z2 interface IReferenceable 
means that an object has 1). a folder to store reference objects in and
2). a UID

I have to look at the z3 system.  Though the "convenience" api in AT 
does alot of bad touching of reference objects, most of what they are 
used for is possible straight through querying the reference catalog. 
Persistence doesn't have to be in the form of a full fledged class, but
that is the current paradigm.

A task short after breaking the reference engine out would be fixing the 
AT Reference Field and widget...

> Thank God we have GenericSetup coming along, otherwise the ZODB upgrade
> script would be pretty nasty ;)

/me crosses finger


> Philipp
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642