[Chandler-dev] Stamp/Annotation-related questions

[Phillip J. Eby]

At 04:22 PM 8/10/2006 -0700, Grant Baillie wrote:
>Hello, chandler-dev@ (and pje in particular :):
>
>So, as I plough on through stamping-as-annotations, I found some
>issues that are more related to using annotations than stamping per
>se. They're both cases where the annotation class has attributes that
>aren't repository values. I'd be interested in hearing if my
>strategies for solving these in the schema itself are reasonably, or
>if there's a better way of approaching things.
>
>1) The osaf.pim.Calculated class (essentially, the analog of a python
>property) doesn't play quite so nicely inside Annotations. You can go
>ahead and do
>
>class MyAnnotation(schema.Annotation):
>
>     schema.kindInfo(annotates=pim.ContentItem)
>
>     myProp = pim.Calculated(schema.Text, ....)
>
>
>
>and then code such as:
>
>     MyAnnotation(someItem).myProp = ... something or other ...
>
>works just fine. The problem is that things like attribute editors
>(and indexes) want to talk to items  -- not Annotation/Stamp
>instances -- directly by attribute name. So, they require an item and
>an attribute name in order to edit or index something, but the
>property doesn't appear in the target class (ContentItem above). Is
>there a reasonable way to make this work? For instance, you could add
>a suitably wrapped property on the fly to the ContentItem class, but
>then you would have to be sure that this happened each time Chandler
>ran (i.e. it should happen at class object instantiation time, not
>parcel initialization time).

That's not really practical because you'd have to ensure the code 
containing the annotation got loaded at startup, which isn't always going 
to be the case.

I don't think we can do this without help from the repository.  If there's 
a repository Attribute defined by the Annotation, then the repository can 
place the descriptor on the class when the class gets prepared for 
use.  But this is something we'd need to talk with Andi about, because it's 
a fairly significant feature.

Specifically, we'd need an attribute aspect that denotes an importable
"formula" that handles the computation, so that the repository-supplied 
descriptor could import it.



>2) There are some similar issues with indexes. For instance, it's not
>hard to port the following code (parcels/osaf/pim/__init__.py):
>
>     events.addIndex('icalUID', 'value', attribute='icalUID')
>
>since I can just replace attribute with its full name (or use
>pim.EventStamp.icalUID.name if I don't want to hard-code the string).
>However, compare indexes are trickier, since they take a method name,
>e.g.
>
>     events.addIndex("effectiveStart", 'compare',
>compare='cmpStartTime',
>                     monitor=('startTime', 'allDay', 'anyTime'))
>
>Here again I can use fully qualified attribute names in the monitor.
>However, the (str) value of compare keyword has to point to a method
>on the item class, not the annotation (stamp) class (since the
>collection, which is what's being indexed, contain items). Typically,
>though, I'd expect to write a method on EventStamp that does
>'cmpStartTime', so to do this I'd again have to wrap the method and
>add it to the target class somehow.

We'll need to ask Andi about this one too; the solution would probably be 
similar.

Of course, in both cases, it could be made to work via Annotation inserting 
descriptors on the base class -- but *only* if the annotation type can be 
guaranteed to have been imported by the time the attributes are used.  For 
the built-in stamps it's not hard to guarantee that, since they're defined 
in the pim package, which has to be imported before anyone could create any 
other stamp types or content kinds.  But by their very nature, it's quite 
difficult in the general case to guarantee that an Annotation is imported 
before you use an annotated item for something.

Still, the "insert a descriptor automatically" trick would solve the 
immediate problem, so maybe we should do that in the short term.