What you're essentially suggesting is putting this code in the model and I don't think it goes there. The various strings that get displayed on the view are for the purposes of the view only. They don't have any use in the model.
I explored using Transformer's some more because, after I wrote my last response, I thought that it really is a Transformer that I need. Unfortunately, I can't see any way to get access to the Transformer instance that is attached to a binding. It would work out if I did. In my View Controller's awakeFromNib:, I could iterate through all of the Transformer instances and tell them what transform to do. In the end, I may just bite the bullet and create the 20 Transfomer objects. It will just be yucky code. Jean On 2010-02-28, at 1:49 PM, Chris Hanson wrote: > On Feb 27, 2010, at 11:34 PM, Jean-Henri Duteau wrote: > >> BTW, I've already considered a Transformer. The problem with that is one of >> code bloat - I have multiple fields on the view that are derived from this >> one attribute. I haven't figured out a way at design time in IB to make one >> transformer handle the different transformations. > > Maybe instead of being a single attribute (by which you mean it’s a string, > URL or some such value class), your model object should have a relationship > to another model object that you can manipulate more directly. > > Then that other model object can have a -stringValue or -URLValue (or > whatever) method to “format” itself as the appropriate value class when you > really it in that form. (And perhaps a setter or initializer from that value > type as well.) > > For example, if I were writing a file-transfer application, I wouldn’t > directly use NSURL to represent the host, port, directory, protocol, etc. > I’d use some other (fully mutable) model object that can return itself as a > URL. My UI would be bound to that other model object, and only when I need a > full URL would I ask that other model object for an equivalent NSURL instance. > > — Chris > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
