[Chandler-dev] It's 'about' time to deal with redirections...

[Grant Baillie]

Hi, Brian

I think Bryan's point is that we remove displayName from Item, as  
well as the repository API (getItemDisplayName()) that uses it.  
You're right that having a generic and occasionally localized  
attribute like that doesn't work.

ContentItem will have displayName, but it's the user-settable  
attribute (like email subject, etc) that you are calling 'title'.  
Bryan wants to call it 'displayName', because that will fit well with  
'displayDate' and 'displayWho' : they're all the values that are  
displayed in the summary table.

--Grant

On 31 Oct, 2006, at 16:35, 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
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev