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: mmalcolm crawford <email@hidden>
- Date: Wed, 20 Apr 2005 00:35:42 -0700
On Apr 20, 2005, at 12:11 AM, Corey O'Connor wrote:
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 first question that comes to mind is, is it possible for the
value of a model object's attribute to be valid, but for it to "not
make sense" as far as the user interface is concerned? This seems
unlikely?
If this is not the case then philosophically validation methods
should probably be the answer -- you should be capture the invalid
value before it's presented to the user. The reasoning here is that
the logic that determines validity really belongs with the model
class. You don't want to scatter business logic around in your user
interface...
So:
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?
Without knowing more about exactly what scenario you have in mind,
and without thinking about it too deeply (I'm tired too! :-) I
suspect not.
Re (*): There is, of course, nothing to stop you invoking validation
methods directly should you wish. You might also consider
implementing a single method (you might call it, for example, - (BOOL)
validateForUpdate:(NSError **)error) that invokes all the other
validation methods...
All this apart, if you want to pursue your original course you might
consider using value transformers. You could implement one to check
for null values, for example. If the input value is non-nil, it
passes it through. If it's nil, it logs an error. All this will do,
though, is to log a message -- it's not possible from the value
transformer itself to determine what the model object and attribute
were. If you really need this then you might create your bindings
programmatically and assign customised (they know what their keypath
etc. are) value transformers to each. This will be long-winded,
though...
mmalc
_______________________________________________
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