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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
