Feature suggestions for easier debugging of Cocoa Bindings.
Feature suggestions for easier debugging of Cocoa Bindings.
- Subject: Feature suggestions for easier debugging of Cocoa Bindings.
- From: "Corey O'Connor" <email@hidden>
- Date: Tue, 19 Apr 2005 15:17:43 -0700
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:
This email sent to email@hidden