On Mar 2, 2011, at 1:44 PM, Joanna Carter wrote: > Hi Quincey > > Many thanks for taking the time to look at this issue. > >> This has come up at least once before, and the approach you're using was >> suggested. I think it has some academic interest, but I'm not sure that it's >> of great use in practical applications. > > I would agree that it is not something that I would normally consider as > major part of application design. > > As someone who is very well known in the Delphi world, I seem to be doing > quite a bit of "evangelism" about Mac development and most Delphi developers > haven't even heard of MVC, design patterns and separation of concerns.
Delphi developers may not have heard of it, but they do it by accident. They place all of their controller code in a TForm subclass; rarely do they do something in the TForm subclass that actually modifies what a standard TForm does. Instead, the subclass exists only as controller code for the form (aka: the "view"). They typically do have the model somewhere else (ie: TDataModule), and interact with it in the Form subclass. Indirectly, they do Model View Controller by the way Delphi is designed. In AppKit the File's Owner is generally now the "TForm subclass" replacement (ie: the controller). > > The kind of RAD development that Delphi (and Visual Studio) seem to encourage > tends to end up with all the code in the form classes; people are used to > doing everything "in the UI", filling list boxes with strings in the form > designer and having to get the strings back from the control when required > for manipulation. > > My aim, in the tutorial, was to show non-Mac programmers that they could feel > "safe", in that they could, in theory, easily display and manipulate a list > of strings. NSTableView is not like a Win32 Listcontrol, which is what Delphi's TTreeView/TListView is based off of. It is more like TVirtualTreeView, where the content is always queried, instead of placed inside. A good Delphi -> AppKit tutorial would probably be showing people how to hook up the File's Owner, add outlets, add actions, and the hook them up in IB. All those things you basically got for "free" in Delphi by dropping down a component and double clicking on it. --corbin (known in the Delphi world about 6 years ago) > > Normally, as you allude, I would expect to be using the NSTableView and > NSComboBox to be displaying and choosing "proper" objects, based on a > particular property. > >> One thing I notice is that your transformation of "string" into a >> NSMutableString property *isn't* KVO compliant. It would be if all the other >> NSMutableString methods modified the underlying string data via >> 'setString:', or issued 'will/didChangeValueForKey:' pairs. I'd bet they >> don't. > > You have a good point there. It definitely comes into the classification of a > kludge :-) Nonetheless, I a not expecting anything to be observing the change > to the "string property"; after all, the whole point of the exercise is > mainly to allow manipulation and editing of lists of NSMutableString > instances in controls, rather than being KVC-compliant as in editing > properties of other objects. > >> The other issue is that it almost always turns out that the string fits in a >> larger design which makes it natural for the string *value* to be a property >> of some other object, so the hack of making it a property of NSMutableString >> isn't really necessary. That's why I think your example is a bit academic. >> (Of course, you can probably find some real examples where the "string" >> property approach feels natural.) > > Agreed; see my comments above :-) > >> I don't understand why you're using 'will/didChangeValueForKey:@"values" >> withSetMutation:NSKeyValueUnionSetMutation usingObjects: ...' for a property >> that's a NSArray. The documentation says these methods are for "unordered" >> collection properties -- i.e. NSSet properties. Chances are it's harmless >> doing this the wrong way, but I wouldn't be surprised to see some UI >> misbehaviors show up at some point. > > Hmmm, yes I did realise the difference in terminology but… it works!!! Would > it be sufficient to simply use will/didChangeValueForKey, without the set > mutation part, to prompt the NSArrayController to update itself? > >> I think there's also a conceptual problem in your use of NSMutableString >> objects to populate your list. In a lot of cases, when a property value is >> to be thought of as an attribute or "simple" value, the property value >> objects should be immutable. (Consider, for example, the problem you'd face >> if you tried to rework your tutorial to be a list of NSNumber objects.) What >> happens if one of your mutable strings "escapes" from the list context (is >> returned as a NSString* value of some method, for example), and is used >> elsewhere? Would it be correct that mutating the original string in its list >> should modify the value that had been passed on to a different context? >> Maybe yes, maybe no. There's a small can of worms lurking there. > > Oh yes, plenty of worms :-) But that's what you end up with when you are > trying to help people get out of their "all in one" approach to software > design and into techniques like MVC. > > Joanna > > -- > Joanna Carter > Carter Consulting > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please 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: > http://lists.apple.com/mailman/options/cocoa-dev/corbind%40apple.com > > This email sent to corb...@apple.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
