[Chandler-dev] is a unified displayName a good thing?
twl at osafoundation.org
Mon Apr 3 11:40:51 PDT 2006
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.
> 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
>> 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
>> 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!
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> Open Source Applications Foundation "chandler-dev" mailing list
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
Ted Leung Open Source Applications Foundation (OSAF)
More information about the chandler-dev