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: John Brownlow <email@hidden>
- Date: Tue, 19 Apr 2005 18:50:14 -0400
Couple of points in response:
1) bindings become MUCH easier to debug once you get used to them. I
felt exactly like you did at first but now they feel much more
intuitive. In general, bindings *do* generate useful debugging info
once you are pointing them at an object. The tricky thing is figuring
out how to point at the right object, and how to know when it has
changed. This gets less tricky.
The Cocoa bindings reference is your friend.
The more mistakes you make early on with bindings the better. They tend
to fail in a small number of very similar ways and you learn to
recognize the patterns very quickly.
2) It is easy to do your own logging by placing turnable-offable NSLog
calls in the accessors. Accessorizer will let you do this. It helps. It
is also trivial to subclass the controllers and place logging calls in
them.
3) I think you are wrong about 'no selection' and 'null'. In obj-C it
is perfectly valid to send invocations to nil objects and bindings
should be no different. In trivial cases your model should always
exist, but imagine what happens with a tree of objects, where a leaf
might have no branches. The default behavior is helpful here.
An assert might be a nice feature though.
4) If you think bindings are inscrutable, wait for C******a. You will
be the meat in an inscrutable sandwich.
On Apr 19, 2005, at 6:17 PM, Corey O'Connor wrote:
Last night I went through making a simple ToDo application using Cocoa
Bindings. In the end I was very happy with the quality of application
I could write up in a single night. I was also very happy with the
design of Cocoa Bindings. I think the API is both powerful, and
flexible.
However, debugging them is a pain. I know this has been discussed on
the list before and I don't really want to rehash the issue, but I
thought of two things that would have helped me. Let me know if they
already exist. I've searched the lists, but I'll be the first to admit
I'm not in top form today ;-)
1. In the "enabled", "hidden" and maybe a few others, there are
options to deal with cases like "No Selection", and "Null". These
specify placeholders, which I took to mean: "In case of _blank_, do
this". In the case of enabled, the possible placeholders are
"Unspecified", "No", and "Yes". Those are nice, but there is no
"Assert" option. Which, for most uses, would make the most sense.
I believe the ideal MVC life cycle is: Model exists, then the view
is created to reflect the model, then the view dies. Later, the model
dies also. In other words, the model always exists as long as the view
exists. In this case, anything but an error for "No Selection", and
"Null" (Which I take to mean "the model does not exists") does not
make any sense. The binding shouldn't silently fail and take use one
of the exceptional case placeholders. Some type of visible error would
be very useful.
Admittedly, this life cycle is not always possible. In these cases
the placeholders are a handy feature. I am convinced that for 90% of
the time, these exceptional cases should actually cause (dun duuu) an
exception.
2. Some logging of the key-value encoding and observing would be nice.
This is about the only way I can figure out what end point some key
actually becomes. Does "foo" access [MyObject foo] or [MySuperClass
isFoo]? I know the docs specify search order, but a little bit of
logging would be nice :-)
Likewise, logging of key change notifications would be nice. Not
sure how much logging would be too much to usefully parse. However,
anything would be an improvement.
I had a terrible time figuring out why my binding to
"requirementDescription.validDescription" was not working. Was the
"validDescription" key not properly defined as a dependent? Was the UI
control hitting one of the placeholder cases due to some problem
trying to dereference "requirementDescription"? Or "validDescription"?
Or.....??? I had no idea, but with a few debugging features I could
have figured it out much faster.
Whew, sorry about the rant! All in all, I really like Cocoa Bindings,
but they still next to impossible to debug. :-)
--
-Corey O'Connor
P.S. I'll send these off to apple too, I just wanted the lists opinion
also.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
--
John Brownlow
Deep Fried Films, Inc
http://www.johnbrownlow.com
http://www.pinkheadedbug.com
_______________________________________________
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