Re: Bindings between nib files (again)
Re: Bindings between nib files (again)
- Subject: Re: Bindings between nib files (again)
- From: mmalc crawford <email@hidden>
- Date: Thu, 30 Nov 2006 23:22:36 -0800
On Nov 30, 2006, at 9:10 PM, Keary Suska wrote:
on 11/30/06 6:28 PM, email@hidden purportedly said:
Bindings should usually be between objects within a model or between
model objects and view objects.
Actually, the pattern employed is Model-View-Controller, so bindings
should
be between models and controllers or between views and controllers.
This
facilitates the separation of the presentation layer from the data
layer. In
reality, bindings are just a technology to facilitate near-automatic
dependent relationships between any two objects. It is entirely
sensible to
have bindings between views, or as in your example, between models.
For
example, the enabled state of a button could be bound to the state
of a
checkbox.
This is not the case. Bindings should be made -- through controllers
-- from view objects to model objects. You typically cannot bind one
view object to another view object (you cannot, for example, bind the
enabled state of a button to the state of a checkbox). One of the
more common mistakes developers make is precisely to try to use the
view as the repository of information.
To introduce a model object into this mix could possibly violate
the MVC pattern rule.
It's not clear exactly what this is intended to mean, but it is at
best misleading. The goal of bindings is precisely to keep
synchronised values in a model object and those presented in a view.
Models can be created in nib files, but they usually aren't. The
question about how to make bindings between nibs never comes up
because bindings are made from one nib to some model objects.
Different bindings are made in other nibs to the same or different
model objects.
Again, the binding is to a controller object, and it is entirely
possible
that a needed controller is in a different nib (or even a model
instantiated
in a different nib). If you never have any model objects
instantiated in a
nib, or instantiated by an object instantiated in a nib, you will
either end
up having to set all of your bindings programmatically
Again your meaning here is unclear. As Erik stated, you typically do
not instantiate model objects in a nib file. You instantiate
controllers which in turn manage model objects. The controllers are
typically instantiated in the nib file that includes the view
objects. It's up to the controllers to decide where they get their
information from.
(and isn't the point of bindings using less code?)
Less code does not mean *no code*. It is perfectly reasonable to
create bindings programatically if necessary.
or you will have to proxy all bindings from the nib through a the
files owner and that becomes rather cumbersome with
projects of even moderate complexity.
It is perfectly reasonable in some situations to establish bindings
between nibs via the file's owner (an inspector panel, for example).
The information that is being displayed or edited by the views in a
nib should be stored in the model objects and therefore accessible
from any/all nibs.
I am not sure where you get this. There is nothing inherent in
Objective-C,
Cocoa, or the "model" pattern that automatically allows or requires
a model
object to be accessible by any nib. In fact, the only thing that
defines a
pure model object is that it has data and behavior with no
representational
functionality. And a nib only has access to models that it has been
specifically given access to. Outside of this, a nib has no
accessibility to
any model object whatsoever, regardless of how or where it is
instantiated.
On the contrary, all the objects in an application share the same
address space and can therefore "be accessed from any nib" -- although
that's a "curious" way to phrase it.
Access to model objects should be mediated by controllers; if you bind
a view to a key-path via a controller object, the view doesn't care
where the destination model objects came from. It doesn't make sense
to talk of them as being associated solely with one nib file.
mmalc
_______________________________________________
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