[Chandler-dev] It's 'about' time to deal with redirections...
Bryan Stearns
stearns at osafoundation.org
Tue Oct 31 16:43:25 PST 2006
Hi Brian,
Yes, I'd previously volunteered to do a mass renaming of 'displayName'
to something else, to deal with this issue.
Having started that job a couple of times and realized that it's a huge
task, I'm proposing a different strategy: 'displayName' would become an
ordinary attribute on ContentItem that user-created items would use to
store their title/headline/about/summary value. (Just like 'title', but
with a different name ;-).
I mentioned below that having it as an ordinary ContentItem attribute
would be no different than an attribute with any other name, once Andi
removes the magic underpinnings that gave us localization (and other)
troubles. Thus, there'd be no hard-to-localize 'displayName' attribute
values, except for the one on the Welcome note: Once 'displayName's are
gone from all the non-ContentItem kinds, no other items would have
displayName attributes (so there'd be no localization headache dealing
with 'internal' values).
...Bryan
Brian Kirsch wrote:
> Hi Bryan,
> There has been much talk over the .7 release of removing displayName
> all together.
>
> The ambigious nature of the displayName makes it less than ideal for
> localization.
>
> Since all items have a displayName attribute, it becomes difficult to
> determine which displayNames appear in the UI and thus need translation.
>
> John Anderson was looking in to removing all displayNames from the
> Chandler code base
> at one point.
>
> The proposal was to use an alternate attribute such as title for
> localized displayable values.
>
> I have been off working on Mail and have not given the displayName
> issue much thought as of late.
>
> Perhaps now is a good time to re-raise the discussion.
>
> -Brian
>
> On Oct 31, 2006, at 2:16 PM, 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
>
More information about the chandler-dev
mailing list