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

[Brian Kirsch]

 > 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