Re: Feature suggestions for easier debugging of Cocoa Bindings.

FROM : mmalcolm crawford
DATE : Wed Apr 20 09:35:42 2005

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