Re: Feature suggestions for easier debugging of Cocoa Bindings.
Re: Feature suggestions for easier debugging of Cocoa Bindings.
- Subject: Re: Feature suggestions for easier debugging of Cocoa Bindings.
- From: "Corey O'Connor" <email@hidden>
- Date: Wed, 20 Apr 2005 00:11:01 -0700
On 4/19/05, mmalcolm crawford <email@hidden> wrote:
>
> On Apr 19, 2005, at 7:57 PM, Jeff Laing wrote:
>
> >> My understanding of the latter part of the post was that he wanted
> >> to ensure data integrity, and that's precisely what the validation
> >> methods do...
> >
> > ... whereas what I read it as was "I configured up most of my bindings
> > correctly, but left this one place unconnected. When I
> > dereferenced the
> > missing pointer via bindings, the resulting silence didn't help in
> > locating
> > the problem".
> >
I think what I am trying at is this: Data validation methods can help,
and some form of a verbose mode would be useful. Still, I think adding
a "binding validation" feature that checks a binding against a
constraint would be useful. This is already in there with placeholders
and "Raise on not applicable", but incomplete. Kinda a
view-controller-level counterpart to data validation.
Validation methods check the model data, while I want to be able to
specify constraints that assert if the controller key's model key
bound to a view property is not of the expected form. Validation
methods can only be automatically invoked on the model key if it is
bound to a view's value. * I cannot, however, currently say "If the
model key bound to a button's enable state is null, there is a
problem, so let me know".
The "placeholder" options provide functionality close to what I
want, but seems incomplete. You can specify values for all interesting
forms of the selections model key path, but there is no way to state
that a given option shouldn't ever make sense. For the enable state
and the "No Selection Placeholder" there are these options:
Unspecified, Yes, No. There is no "Should not ever happen" option.
However, having an placeholder option that throws an exception,
instead of producing a substitute value would be inconsistent.
Creating a "binding validation" feature, much like the current "data
validation" feature, is probably more elegant.
I'm kinda tired and hazy at this hour ;-) Sorry if my writing is
unclear. Does it make sense to want a feature to validate the view
binding, and not just a feature to validate the data?
Thanks for the replies!
--
-Corey O'Connor
* As far as I know. The documentation states "Note: Key-value coding
does not perform validation automatically, it is your application's
responsibility to invoke the validation methods. Also, an
implementation of -set<Key>: for a property should never call the
validation methods." While the "validates immediately" property
indicates something in the bindings system will actually invoke the
validation automatically.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden