Re: Design pattern for "per-document" settings
Re: Design pattern for "per-document" settings
- Subject: Re: Design pattern for "per-document" settings
- From: Negm-Awad Amin <email@hidden>
- Date: Mon, 3 Aug 2009 09:35:39 +0200
Am Mo,03.08.2009 um 02:18 schrieb Graham Cox:
Hi all,
I'm just thinking through a couple of problems and wondered if
anyone had anything to say about it...
In my app I have several things that apply on a "per document"
level, for example, the mapping from Quartz co-ordinate values to
some other measurement system, such as millimetres. Different
documents might have different mappings. Other parts of my interface
will want to work with these settings, for example text fields that
set geometric properties such as line width. Many of these text
fields live in floating palettes that respond to different document
windows becoming main, etc.
So what I'm thinking is that I can write a custom formatter attached
to the text fields that can pick up the current main document's co-
ordinate mappings. I'm just not sure what the most efficient and
most straightforward implementation might look like.
I could get every formatter instance to subscribe to certain
notifications, but that requires a lot of code to set up and tear
down as nibs are loaded, etc. Alternatively, I could give the
formatter some class methods that centralise the notification
handling and also keep track of all the individual instances.
Trouble with that is that class methods are global, rather than "per
document", though since most (but not all) of the formatters are
also global in the sense that they are in context sensitive
palettes, that is favourite at the moment.
Or maybe formatters are not a sensible way to deal with this at all?
Is there a better design pattern I'm overlooking?
--Graham
Never tried, but should work:
1. Make a subclass
2. add a property that holds the information
3. add a binding for that property
4. bind the property through the application to get the "active"
dorument
_______________________________________________
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
Amin Negm-Awad
email@hidden
_______________________________________________
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