Re: (no subject)
Re: (no subject)
- Subject: Re: (no subject)
- From: "I. Savant" <email@hidden>
- Date: Wed, 23 May 2007 13:14:55 -0400
Say that I have an NSTableView with two columns, firstName and
lastName. Say that some marketing hack insists that I store these
combined as one string.
Maybe I'm not quite understanding you here. Take the rest of this
message in its entirety with that in mind, but ... The marketing hack
should have absolutely *zero* input into the *implementation* of the
application. That's just ridiculous. What it *does* is the user's
business, how it does it is not. What does the hack actually want to
*do*?
I'm assuming the following: 1) You still need to keep first/last
names logically separate (why wouldn't you? in this day and age
there's simply no good reason for combining this information ... it's
imprecise and so not future proof). 2) The marketing hack doesn't
really know anything about software engineering.
That said, *storage* should be done as a separate given/surname,
since that's how people's names work, how other people look up / sort
their names, it's easier to manipulate, etc. Anything less will be
losing precision for no good reason. If the hack simply wants to be
able to *view* the name as a combined name, then that's fine ...
however: if they want to *edit* it as one long string (while keeping
the concept of first/last separate), there's something very important
to consider: People have odd names like "van de Graffe" ... I imagine
some people even have spaces in their first names. How do you propose
to guarantee first/last name will be kept logically separate? In this
case, storing the whole name as a single string makes it nearly
impossible to recover precision of first/last with 100% accuracy. BAD
MARKETING HACK - STICK TO MARKETING.
So ... it's settled, then, I trust: Retain the precision when
storing the names in your model. First, Last, not both as one.
IF HACK ONLY WANTS DISPLAY:
If you have a "Person" model object, why not create a -fullName
accessor? The real properties will be firstName and lastName, while
fullName returns a concatenation of the two.
For proper KVO goodness (ie, changing lastName automatically updates
anything bound to fullName), use
+setKeys:triggerChangeNotificationsForDependentKey: in the +initialize
method of your Person object. Make the full name uneditable in your
view and you're done. If you want to edit, edit the correct fields.
IF HACK INSISTS ON EDITABILITY:
This is more work but a transformer is *not* the way to go due to
the difficulties mentioned above.
You might try creating a custom cell that displays / provides
editing for two separate strings. There are lots of examples of
various custom cells ... look at ImageAndTextCell in your
Developer/Examples folder .. it's got much of what you need to
understand the concept.
This way, it will appear in your view as one name but allow editing
without the need to attempt to parse a full name into first/last name
(given that such a thing is incredibly complicated for names more
complex than "John Smith"). In the case of a table, you'd probably
want to use the data source methods since using bindings won't really
save you much work with a compound, custom cell (someone please
correct me if my assumption is wrong - I'd love to know better). You
can still use an array controller though (reference its
"-arrangedObjects" in your data source methods). Don't shy away from
<NSTableDataSource> ... it's still got many valid uses!
... in general, I suggest going back to this marketing hack and
diplomatically requesting clarification on the ultimate goal, not how
s/he thinks it should be implemented. The former is meeting the
"customer's" request, the latter is none of their damned business. ;-)
Be prepared to be insistent that s/he nevermind "how" ... just that
they tell you what their ultimate goal is.
--
I.S.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >(no subject) (From: Sam Stigler <email@hidden>) |