Re: User interface validation doesn't work, right?
Re: User interface validation doesn't work, right?
- Subject: Re: User interface validation doesn't work, right?
- From: Keary Suska <email@hidden>
- Date: Fri, 3 Jul 2009 08:30:33 -0600
On Jul 2, 2009, at 11:52 AM, Bill Cheeseman wrote:
On Jul 2, 2009, at 12:24 PM, Keary Suska wrote:
Because the two protocols in question are formal protocols, the
@interface declaration must specify conformance. If it doesn't,
then no assumption of conformance should be made. Pure and simple.
Also, protocol conformance is not inheritable in Objective-C.
1. Taking that last point first, the Objective-C 2.0 Programming
Language document says this: "A class is said to conform to a formal
protocol if it adopts the protocol or inherits from another class
that adopts it." I believe, without checking, that this was true in
1.0, also. I take that to mean that protocol conformance is in fact
inherited. That makes sense, because a protocol is simply a promise
that certain methods are implemented, and implemented methods are
inherited by subclasses.
Yeah, I misspoke there. You are absolutely correct.
2. The key question for me is your first point.
The way I work around the lack of automatic validation for buttons
is this: In my window controller, I implement -
validateUserInterfaceItem: and declare that my controller conforms
to the NSUserInterfaceValidations protocol. That's exactly what
NSDocument does, as I understand it. Since user interface items are
not automatically validated, I force validation by implementing
NSWindow's -windowDidUpdate: delegate method so that it loops
through all subviews of the window calling my controller's -
validateUserInterfaceItem: protocol method. (I could use something
other than -windowDidUpdate: to trigger the protocol method if
efficiency becomes an issue, but at this point doing it every time
the window updates works just fine. I am aware that Apple is
struggling with efficiency concerns in automatic validation of
toolbar items.)
Why not use bindings or KVO? They will likely be much more efficient,
easier to implement, and provide more control.
Now here's my question for you: In my controller's implementation of
-validateUserInterfaceItem:, I can either limit the items that I
enable/disable by checking whether their class is NSButton (which I
know responds to -action and -setEnabled:, and I can confirm that
programmatically). Or, instead, I can limit the items by checking
whether they conform to the NSValidatedUserInterfaceItem protocol.
If I do the latter, I have to declare a subclass of NSButton and
declare that it conforms to the protocol because NSButton does not
itself declare conformance, and of course I have to set the type of
my buttons to my subclass type in Interface Builder. Either
technique works (I know because I've already done it), but testing
for compliance with the NSValidatedUserInterfaceItem protocol
somehow seems purer to me.
The whole approach seems problematic to me. I would say that you
should use the API when you can, and work around it only when you
can't (I am full of ambiguous maxims these days!) I.e., allow menus
(includes popups) and toolbars and any other object that conforms to
NSValidatedUserInterfaceItem proper ("proper" in the Objective-C view,
as opposed to your view--this has been hashed out enough I won't
elaborate) to use their automatic validation, and use a "home grown"
solution for everything else. The latter solution also preferably
working with the API rather than around it (e.g. KVO), because you can.
Where would you come out on this question? From your comments, I
assume you would say I should not subclass NSButton and declare it
as conforming. Then I would have to simply check whether the class
of an item is the NSButton class. You might also insist that I
should not name my validation method -validateUserInterfaceItem:,
but something else such as -updateWindow, because I risk confusing
people about what my controller really does. In that case, I'm back
where most Cocoa applications were before Cocoa bindings were
invented, declaring a custom -updateWindow method and calling it
from -windowDidUpdate or whatever.
Yes, because as others point out, we don't actually know how (more
importantly, when) validation is called, so we don't know how to
duplicate it. I doubt that declaring conformance is sufficient.
I would prefer to do things the NSUserInterfaceValidations way, so
that I'm ready when Apple gets around to making user interface item
validation automatic, which I really think it ought to do (with an
on/off switch). (Apple will probably say I should move on to Cocoa
Bindings and get over it.)
I would agree with Apple, or as a concession, say use KVO.
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden