Re: Can a value transformer get its own registration name?
Re: Can a value transformer get its own registration name?
- Subject: Re: Can a value transformer get its own registration name?
- From: Jim Correia <email@hidden>
- Date: Thu, 12 Apr 2007 15:09:29 -0400
On Apr 12, 2007, at 2:33 PM, Bill Cheeseman wrote:
What I'm not getting is how you actually use a value transformer
instance in
your scenario, if you don't rely on the registration name to
distinguish
between instances having different behavior. The value transformer
field in
the view binding pane in the IB inspector requires a registration
name.
Or are you saying that you do rely on the registration name, but
only to get
the right instance -- and that the instance's behavior is then
determined by
the iVar you embedded in it when it was initialized?
Exactly. The registration table is a convenience for specifying
transformers by name in nibs (or other code which needs to look them
up by name). The registration name should be meaningful to those who
need to find the transformer by name, but shouldn't be overloaded to
encode state information that should be specified in transformer
instances themselves.
An example
typedef enum {
UppercaseStringTransformation,
LowercaseStringTransformation,
ReverseStringTransformation
} StringTransformationType;
@interface StringMungerValueTransformer : NSValueTransformer {
@private
StringTransformationType transformationType;
}
- (id)initWithTransformationType:(StringTransformationType)
transformationType;
@end
@implementation StringMungerValueTransformer
- (id)transformedValue:(id)value;
{
switch (transformationType) {
...
}
}
@end
For registration, I'd do
NSValueTransformer *transformer;
transformer = [[StringMungerValueTransformer alloc]
initWithTransformationType: ReverseStringTransformation];
[NSValueTransformer setValueTransformer: transformer forName:
@"ReverseStringTransformer"];
// register with a 2nd name for legacy code/nibs
[NSValueTransformer setValueTransformer: transformer forName:
@"BackwardsStringTransformer"];
[transformer release];
etc...
Jim
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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