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

Alec Flett alecf at osafoundation.org
Tue Apr 18 13:18:07 PDT 2006


>> I know Alec was working on a writeup on this topic as well.  Alec, 
>> I'd be curious to know if Katie's ideas match up with yours?   
Yeah, I actually had a whole writeup and thunderbird must have crashed 
before I sent it. Lame :)

Anyhow, I've been meaning to rewrite stuff  and I like Katie's summary:

> I'm open to other proposals, just wanted to make the point that user 
> data shouldn't be localized and should be indexed.
I just finished up the table header attribute display to be fully 
localized and it got me thinking about the different ways that 
displayName applies. The three big cases I came up with are Kinds, 
Attributes, and Item instances. What follows is my understanding of how 
these are used in chandler today.

One of the key bits of this is the notion of Item instances vs. Kinds & 
Attributes. Leaving aside for now that Kinds and Attributes are 
technically also Item instances, there is a difference in the way we use 
these things in the code.

And Item instance takes place in the form of user data, (Notes, Tasks, 
Events, etc) or in the form of internal objects that we use to maintain 
the rest of chandler (i.e. Blocks, TimeZone information, Preferences, etc)

Item instances generally do not come with much in the way of pre-set 
attributes beyond really basic things like "New Event" or "Untitled" - 
and if anything I think those values are really functions of the view 
that is presenting them - i.e. the Chandler UI might set an event to say 
"New Event" for the user, so that the user knows to type a new name. the 
string "New Event" is not necessarily part of the domain model. These 
values tend to be dynamic because the user could change them at any time.

Kinds and Attributes are slightly different though: They really are what 
most of the domain model is, and there is really only one of each Kind 
or Attribute - one CalendarEvent kind, one Task kind, etc. the 
displayName of these Kinds generally do not change, but as of today they 
do appear in the UI in more static elements like the Table column 
headers. This means they do in fact have to be localized, even though 
they're part of the Domain Model, but of course they don't need to be 
indexed.

I guess I began this to try to understand if things in the Domain Model 
needed to be localized, and that's what's happening here. However, in 
the same way that "New Event" is a function of the view, its also 
possible that the displayName of each Kind/Attribute could also be a 
sort of function of the view (i.e. the UI), but I can't think of a 
practical way to make it part of the view.

So in any case it seems like the semantic difference between a 
Kind/Attribute's displayName and an Item Instance's displayName is 
whether or not it is indexed and not too much else. If that's the only 
difference, I would probably vote that we continue using the 
"displayName attribute override" mechanism that Andi introduced me to 
last week, where everything has a localizable displayName, but that 
ContentItem has its own displayName that is simply overridden to 
indicate that it should be indexed.

So the answer to my original query (the subject of the thread) is, IMO, 
"it is not necessarily a good thing, but it doesn't seem to bad either."

Alec


More information about the chandler-dev mailing list