Object pool used by view components

[hesten]

Hi All

I have a potential monstrous amount of text fields being created and removed at runtime, and they all need a non-system font, which means that I need a TextFormat object for all my text fields.
So I thought I'd just create a TextFormat object for each color and size and font (instead of one per text field) and reference them instead of creating new ones.

My problem is where to keep them. Would it be ok to store them in a Proxy and let a given view components mediator fetch the TextFormat object when needed?

Regards

[puremvc]

The GoF Flyweight Pattern¹ 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>

¹Here is a short discussion of the flyweight pattern:
http://www.lepus.org.uk/ref/companion/Flyweight.xml

[hesten]

That sounds like a good idea, thanks.

Where would you put factories in the folder structure? Even if it constructs view related objects is it really a view? Or would you have a factories folder (on previous projects I would have at "builders" folder)?

[puremvc]

Yes, I'd specifically call it factories and make it a sibling to components in the view folder, yielding a package like:

:

com.me.myapp.view.factories (for PureMVC Standard Version)
com.me.myapp.modules.modulex.view.factories (for PureMVC MultiCore Version)
-=Cliff>