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

[Ted Leung]

Alec,

Did we come to resolution on this?  Is there some additional  
discussion that we need?

Ted

On Apr 3, 2006, at 11:59 AM, Brian Kirsch wrote:

> > 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.
>
> +1
>
> Brian Kirsch -  Cosmo Developer / Chandler Internationalization  
> Engineer
> Open Source Applications Foundation
> 543 Howard St. 5th Floor
> San Francisco, CA 94105
> http://www.osafoundation.org
>
>
>
> Ted Leung wrote:
>
>>
>> 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)
>>
>>
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> 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)