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

Katie Capps Parlante capps at osafoundation.org
Mon Apr 17 21:31:33 PDT 2006

Ted Leung wrote:
> So is the rule to display the title in preference to the displayName?   

Yes, in the context of the summary table and the detail view. Some 
contexts would use displayName, like the column headers for attributes.

It is possible that the summary table and detail view we have through 
1.0 will only need to display things-that-have-titles -- "contentItem" 
or its moral equivalent once we've revamped the domain model.

Perhaps we don't need an equivalency or relationship between displayName 
and title. I suspect you'll sort this out while tackling user defined 
attributes and other related domain model issues in alpha3.

> It seems to me that the only time that displayName is really that useful 
> is when the item being displayed is an attribute name -- I can imagine 
> localizing that data, I can't imagine localizing data entered by the 
> user.    

Agreed. One could imagine other contexts for blocks, events, etc. having 
displayNames. The rule could be, a "displayName" tends to be set by a 
programmer or scripter, not an end user.

I guess you could have a displayName that was "Untitled
> foobar", which might make some sense to localize, except that when 
> display a summary view full of untitled items, you' just see a pile of 
> "Untitled foobar" rows.

I think this only makes sense in something like a gui builder, where the 
end user is halfway to being a programmer/scripter. imho, it only makes 
sense to call something "untitled foobar" if you expect the user to 
rename it.

> 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?   

I'm open to other proposals, just wanted to make the point that user 
data shouldn't be localized and should be indexed.

If this is
> going to get into alpha2, we are going to need to come to agreement 
> fairly soon.



More information about the chandler-dev mailing list