[Chandler-dev] is a unified displayName a good thing?

[Ted Leung]

On Mar 31, 2006, at 1:09 PM, Alec Flett wrote:

>
> Andi pointed out to me that we can actually have an overridden  
> attribute at any level in the class hierarchy.. this means we can  
> say, for instance
>
> class Note(...):
>    displayName = ....
>
> and that displayName will override any underlying displayName,  
> including any attribute aspects like 'indexed'
>
> This sounds like the optimal solution to the PyLucene problem I  
> described below. Does anyone have any objections to this? Ted, this  
> is domain model stuff.. how does this sound to you?

If you look at Bug 1745: <https://bugzilla.osafoundation.org/ 
show_bug.cgi?id=1745>, you'll see that there's another issue related  
to displayName /  title, which is localization.   I think that the  
localization stuff points to a separate Title attribute rather than  
displayName.   I suppose that you could even argue that the two names  
(title and displayName) are reversed in their meanings if you have  
both of them - title being the "system" name for the item and  
'displayName' being the text that is localized, indexed, and   
presented to the user.

Ted

>
> Alec
>
> Alec Flett wrote:
>> So we have this great attribute, 'displayName' which is used all  
>> over the place from Block to CalendarEvent and comes in quite  
>> handy most of the time.
>>
>> I've recently run into a snag with it however.
>>
>> In the repository, you can indicate that an attribute is indexed  
>> by PyLucene simply by adding a 'indexed=True' to the attribute  
>> definition.
>>
>> The problem is that from a user's perspective we only want to be  
>> searching 'Note'-based items... not all Items in the system.  
>> Further complicating this is that things like attributes are also  
>> Items.
>>
>> This means that if you do a PyLucene search for "a" you'll get  
>> literally hundreds, if not thousands, of results, even if you only  
>> have "Welcome to Chandler" in your All collection. Now of course  
>> it is easy to filter out the items that don't derive from Note and  
>> only display them... but it seems like a lot of work to iterate  
>> 1000 items that we know will never be displayed just to get 1  
>> result back.
>>
>> There are a few options that I can think of, and I'll indicate my  
>> preference below:
>> 1) change the repository so PyLucene only indexes one particular  
>> type of Item... maybe a specific subclass or something.
>> 2) don't use displayName for user-visible Items, and don't put  
>> 'indexed=True' on displayName. Instead, come up with a new  
>> attribute, say 'title' that shows up only on Note-based items, and  
>> put indexed=True on that attribute.
>>
>> Either way the end result is that when you search PyLucene, we  
>> don't have to filter out 1000 non-Note items.
>>
>> I vastly prefer the 2nd option, and I think it makes a lot of  
>> sense from a domain model perspective anyway.
>>
>> I realize there is a lot of history here... (Andi says "Brian made  
>> me do that" when we found some oddities in chandler.pack) but  
>> honestly a Note-based item's "title" is a dynamic, changing part  
>> of a user's data, while a displayName tends to be a more static  
>> description of a well known Item. I see a semantic difference and  
>> we should probably reflect that in the schema.
>>
>> When you're searching PyLucene, we don't want to say "only find  
>> these things" - instead we want the things to indicate if they  
>> want to be found. The title of an event wants to be found. The  
>> displayName of a MenuItem block doesn't!
>>
>> Thoughts?
>>
>> Alec
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> 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

----
Ted Leung                 Open Source Applications Foundation (OSAF)