Re: Controllers and Business Rules
Re: Controllers and Business Rules
- Subject: Re: Controllers and Business Rules
- From: Scott Stevenson <email@hidden>
- Date: Wed, 29 Sep 2004 01:18:39 -0700
On Sep 28, 2004, at 9:50 PM, Joseph Jones wrote:
In the brave new world of Bindings, we have new classes that are used
to
handle model modification (NSController and it's subclasses). Since the
controllers allow direct modification
I think this is somewhat misleading.
Bindings are about defining relationships. The relationships are not
between instance variables but keys. A key doesn't have to map 1:1 with
an instance variable. While this may seem somewhat obvious (or not),
the weight of this fact is substantial. It gives you a lot of options.
My assumption is that the new way for enforcement to take place is to
subclass the appropriate controller you need and to insert your rules
into
overrides of canAdd, canRemove, isEditable, etc. But this is only an
assumption and I have no way of knowing if this is correct or not, or
good
or not.
I think this is probably not the right approach.
I think of NSController as something used to support the view. When you
give an NSController subclass too much knowledge of the model, you're
decreasing the value.
Also, bear in mind that NSController is not meant to completely replace
a traditional controller. It's supposed to make it easier to do the
most common things that people write the same code over and over for
(datasource methods, for example).
Almost all examples and discussions deal with very simple examples that
don't seem to provide any explanation of rules enforcement in this
brave new
world. While I think bindings are a great technology, without a means
for
rules enforcement it seems limited in real world use.
Since you're using pretty generic terms, it might help to give some
examples of what you mean by rules enforcement.
In a simple case, a key will simply stand in front of an instance
variable. For example:
NSString *name;
- (NSString *) name;
- (void) setName: (NSString *)newName;
But this is by no means the only way to do it. For example:
NSMutableDictionary *properties;
- (NSString *) name;
- (void) setName: (NSString *)newName;
You could bind to "name" without a name instance variable having to be
present. In this case, the 'name' accessors know how to find the value
in the properties dictionary.
Some other options for enforcing rules:
Key-value validation:
<http://developer.apple.com/documentation/Cocoa/Conceptual/
KeyValueCoding/Concepts/Validation.html>
NSValueTransformer:
<http://developer.apple.com/documentation/Cocoa/Reference/Foundation/
ObjC_classic/Classes/NSValueTransformer.html>
The idea here is to let go of the idea of trying to run the whole show
with line after line of individual instructions, and instead write code
bits at key points that dictate the rules specific to your application.
This means a whole lot more functionality for free (today and in the
future) and less app-specific code.
If you need more control, you can also override KVC and KVB methods.
- Scott
--
Tree House Ideas
http://treehouseideas.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