Hi, Phillip
Thanks for your thoughtful thoughts. I hadn't really thought of the
potential import-ordering issues you brought up, below. As I
understand things, the plan in the "Dashboard date and lastmodified
proposal" thread will deal with the Calculated case.
For the compare index case, then, we would eventually want the
repository to accept an Importable (not just a method name) for the
'compare' keyword argument. As you said,
Still, the "insert a descriptor automatically" trick would solve
the immediate problem, so maybe we should do that in the short term.
Yes, it is working: For now, I created a Comparator decorator for the
compare index methods; this way AnnotationClass knows to add
appropriately wrapped functions to the target class when creating
Annotation classes.
--Grant
On 11 Aug, 2006, at 13:50, Phillip J. Eby wrote:
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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
