The GoF Flyweight Pattern
1 is a good match for this problem.
I would make a FlyweightFactory that creates and caches your TextFormat objects on demand. Register a Meditator for the FlyweightFactory.
Here's a good point to remember:
It doesn't matter that a mediated ui object is not a visible component of the View hierarchy. No need to store view components in a Proxy just because Proxies tend to hold things. They hold domain data and shouldn't be concerned with the View at all.
So, we'll use the FlyweightFactory to hold some objects used in the View tier and the FlyweightFactoryMediator mediates communications with it. Then, when ViewComponentX needs a TextFormat object from the FlyweightFactory to be set on one of its text fields, have ViewComponentXMediator send a notification with a reference to the text field. The FlyweightFactory should be interested in that note and have its FlyweightFactory set the appropriate TextFormat object on the text field.
Now the problem is one of how to indicate which TextFormat object we want to set on the text field. If there were a fixed, managable set of types, you could define constants and use the type parameter of sendNotification to pass this information to the FlyweightFactory mediator. But it sounds like you've got a very long list of permutations.
So, you could make a business object that has the properties of color, font, style, size and a reference to the text field. Send this BO as the body of the notification. The FlyweightFactory could have a method that accepts this business object, and uses the info to create or fetch from its cache the appropriate TextFormat object and apply it to the text field.
The FlyweightFactoryMediator simply plucks the BO from the notification and invokes the method on the factory with it.
-=Cliff>
1Here is a short discussion of the flyweight pattern:
http://www.lepus.org.uk/ref/companion/Flyweight.xml