I am building a custom view that can display and edit some polymorphic objects. Furthermore, the objects can be composite, i.e. contain child objects hierarchically.
Now I want to bind this custom view to the model through a controller (NSTreeController in my case). In the examples I have seen (GraphicsBindings, Sketch), the custom view, when it needs to draw objects or hit test objects or whatever else, it queries the controller for the array of model objects and sends them the corresponding message "draw", "hitTest" etc. defined in the model interface. Is this actually the design everybody is using? IMHO such design introduces an implicit dependency between the view and the model. What if I want to have two or more views to view the model objects? I would have to have drawInView1, drawInView2 etc. messages in each model object's interface. Isn't it better to have the draw and hitTest messages encapsulated in the custom view's interface instead of the model objects (perhaps using the Visitor pattern to account on the object polymorphism)? This is my first question. Here's the second question. None of the mentioned two designs allow the custom view to add view-specific state to the model objects it displays or edits, in other words, the custom view, being a single "long and flat" object, treats the model objects as "stateless" objects. When the custom view becomes quite complex, it may be the case that the model objects need to have some transient states specific to this custom view only and therefore not included to the main model. For example, a model object displayed in the custom view can be "expanded" or "collapsed" which in no way affects the model or the other views of the model, so this property should not be included to the properties (even transient) of the model, to avoid (again) implicit dependencies between model and views. For this purpose, before I switched to using Cocoa bindings, I would create a "view object" counterpart for each "model object" displayed and edited in the custom view, and bind each pair of such counterparts to observe each other (manually using a technique that reminds KVO). The "view objects" encapsulate the draw and hitTest messages polymorphically, and also can have a state associated with the model object in context of the custom view. In addition, with such design, the custom view can be used independently on the model - even if there is no model and controller, you can still use the custom view by manipulating its unbound "view objects". So the second question is - whether such design is good or bad and implementable in context of Cocoa bindings? (I wonder if it is possible to bind each model object to a view object without too much manual glue code). If not, how would you work around the mentioned problem? _______________________________________________ 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 [EMAIL PROTECTED]
