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

Alec Flett alecf at osafoundation.org
Fri Mar 31 13:09:10 PST 2006

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?


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

More information about the chandler-dev mailing list