Re: Bindings - registering change notification for multiple keys
Re: Bindings - registering change notification for multiple keys
- Subject: Re: Bindings - registering change notification for multiple keys
- From: dreamcat7 <email@hidden>
- Date: Wed, 2 Jul 2008 15:06:31 +0100
On 2 Jul 2008, at 12:14, Ken Thomases wrote:
See my other message. Turns out I was wrong about
NSMutableDictionary and KVO. :(
Yes, but your main point which was not to expose it - still true.
If you really need for there to be a dynamic set of properties,
you can accomplish that using valueForUndefinedKey: and
setValue:forUndefinedKey:. Basically, you have "virtual"
properties -- they won't have proper individual accessors, but the
above-named methods will be invoked whenever anything tries to
access them via KVC, and in your implementations you can simulate
their existence (by accessing the NSMutableDictionary which is
part of your implementation, for example)
If i understand correctly what you say its actually possible to
override that function for plist-type object ?
You override it in your custom class, e.g. Preferences, which is not
a plist-type object.
I meant to say an object managing a plist or other data store. Sorry.
This is entirely what you interpret it to be.
- setValue:(NSObject*) obj ForUndefinedKey: (NSString*) key
{
// If i have an internal representation of NSMutableDictionary for
the .plist file
[self.myMutableDict_PlistStore setValue:obj ForKey: key];
// If property Key is written with a naming convention, e.g.
prefixed with letters 'PTUI'
// We may might assume it is one of our UI Element keys. And we
may include a handler for this weak type.
Didn't really follow that.
It would be dangerous to allow any arbritrary key value name to
trigger the handler method because any other object may send a setKey
to any arbitrary keypath, or request a key value which was not
anticipated. To offer some protection against that it makes sense to
adopt a naming convention for your dynamic key names.
In other words to identify them loosely with weak typing (as opposed
to 'strong typing'). The keyname recieved by the method can then be
substring matched against the weak prefix identifier(s) to ensure its
really one of the kinds of keys we know how to handle. Otherwise we
would allow the adding and returning of unknown keys for any old
requests leading to unspecified program execution...
And this doesnt invalidate all of your other arguments against using
dynamic keys.
// We can to call our data store-class methods to implement the
common repetitive functionality**
// e.g. [self savePlistStore]; or we cache the PlistStore and save
it when application becomes idle.**
Yeah, you can set a dirty flag and/or queue an idle-time
notification (see NSNotificationQueue and NSPostWhenIdle).
thank you for bringing ( NSNotificationQueue + NSPostWhenIdle ) to my
attention.
That's an important consideration with this approach. Since you're
going totally dynamic with KVC, you lose a variety of compiler
checking on what you're doing. A typo in a key or key path string
could result in a hard-to-notice bug.
< even more comments > ...
From what you've said about maintainability, you seem to think that
having real properties will present a maintainability problem. I
suspect you've got that backwards. I suspect that going with full
dynamism when you don't have to will result in a maintainability
problem.
** and in real-world application i no longer need to wire all
controls to target action "uiSateState". Then binding to the
undefined key 'PTUI(ElementName)' is neater.
Again, didn't follow that. It seems you're carrying on a side
conversation with someone else, maybe?
Yes please ignore, not relevant here.
It is weak-typing, but allows dynamic UI elements. And more
coherent - looking code. This [self savePlistStore] is equivalent
to synthetic property anyPreferences ( which Ken describe also for
dependantKeys method below).
Well, not quite equivalent. I think what you're saying is that
using the setValue:forUndefinedKey: gives you an opportunity to save
your model, and therefore you don't need to have an observer
watching for changes to properties of the model, if that observer
were only doing so in order to save the model. So, while I disagree
that savePlistStore is "equivalent" to anyPreferences, I can see how
setValue:forUndefinedKey: would obviate the need for observing
anyPreferences.
Yes. The place we can to hook in our common handler code for all/or
subset of the individual properties belonging to that class/object.
Depending whether using dynamic or static properties for the class.
Sorry that was not very clear for the other readers.
Again, it seems to me that you're taking dynamism to an unreasonable
extreme.
If not then it might be a workaround to subclass the NSObject class
to find the list of properties that belong to it.
If you use the Objective-C 2.0 "declared property" (@property)
feature, it does provide property introspection if you insist on
going that route. Remember, though, that you don't want the
"anyPreferences" property to depend on _every_ property of the
class, because that would make it dependent on itself. Even beyond
the issue of making a property depend on itself, I suspect you'll
find that the Preferences class has several properties which should
not affect "anyPreferences" -- for example, if the Preferences class
maintains a reference to its store by file path. So, I think you
will always want to state explicitly in code the list of key paths
on which "anyPreferences" depends. Doing otherwise opens you up to
unintended consequences in the future.
Also remember that, if you implement "virtual" properties using the
undefined-key methods, then there's no such thing as "the list of
properties for this class". With that much dynamism, then each
_instance_ has its own set of properties which can change at will.
Again, would like to echo your view that for a more maintainable
program, then bestter to try the static properties approach first. And
if that doesn't work then dynamic ones are possible, but can be a
danger. In fact, usually re-thinking the workings of the program will
produce a satisfactory alternative solution (and without requiring
dynamic key paths / properties). Not to mention the memory-management
concern !
That said, I am still curious to try this dynamic properties method
anyway, just to learn it (and also see the limitations).
_______________________________________________
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