+1
Bryan Stearns wrote:
The time has come to deal with a couple of issues around attribute
redirection:
- We need to index 'who' and 'about' attributes for the dashboard, but
(a) the repository can't index an attribute that's the _source_ of a
redirection (the index gets out-of-date really quickly, leading to
several of my alpha5 bugs), and (b) for 'who', a static redirection
isn't good enough because the 'who' value needs to be determined on a
per-item (not per-subclass or per-annotation) basis.
- A related issue is that we're trying to get rid of the dependence on
the repository's generic 'displayName' mechanism on Item; currently,
'about' redirects to 'displayName' by default (in ContentItem), but is
overridden in several Item subclasses and Annotation classes.
We currently have a mechanism for the Date column that works like this:
- ContentItem has a 'relevantDate' attribute that is indexed and
displayed in the Date column of the dashboard view. There's also a
'relevantDateSource' attribute that's currently used to display the
source of the selected item's Date value (though it's currently not
localized).
- Items (either ContentItem, its subclasses, or annotations on
ContentItem) that want to provide a relevant date do so by
implementing schema.observers that call
ContentItem.updateRelevantDate() when a related date attribute changes.
- ContentItem.updateRelevantDate() calls AddRelevantDates() on itself
any stamping annotations, and the Remindable annotation, and picks one
to update 'relevantDate'/'relevantDateSource'.
I'm proposing that I do something similar for 'who', though I now
think that 'relevantDate'/'relevantDateSource' would be better named
'displayDate' and 'displayDateSource'; I'd do that, and make the 'who'
fields be 'displayWho'/'displayWhoSource'.
We don't appear to need the same dynamic-ness for 'about' as well, so
at least for now, I'd get rid of the redirections from 'about' to
'displayName': we'd index 'displayName' instead of 'about'. Any
ContentItem subclasses or Annotations that wanted to have their own
name for the displayName could use a redirectTo as they do now;
however, anyone who redirected 'about' to some other field would need
that redirection replaced by one to 'displayName' -- for example, the
Amazon parcel has a ProductName attribute and used to redirect 'about'
to it; now, it would have a redirection from 'ProductName' to
'displayName' instead.
If we need to show alternative names for the field in the UI, such as
'Subject' if it's an email, and 'Product Name' if it's an Amazon item,
a separate mechanism will be built to look up a localized name at
display time.
To allow the repository to stop supporting a generic 'displayName'
mechanism, we'd declare a concrete schema.Text 'displayName' attribute
on ContentItem.
Comments?
Thanks,
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
