[TransWarp] Domain model objects as utilities?

[Phillip J. Eby]

At 02:08 PM 10/17/03 -0700, John Landahl wrote:
>Is it possible to load a peak.model.Element-based object in a [Provide 
>Utilities] section using config.provideInstance?  It appears that 
>config.provideInstance is expecting something more component-ish, and that 
>trying to load something model-ish just breaks things in strange ways.

Specifically, it expects to call an IComponentFactory, passing it the 
configuration root as a parent.  So, if you use a class method or a 
function that accepts the parent, throws it away, and then returns an 
instance of your Element, you should be okay.

I would remind you, however, that Element is designed to be a base class 
for (persistent) domain model objects, and also note that I don't 
understand why/how you would ever have 1) a singleton form of such, and 2) 
use it as a utility.


>My use case is this: I have a number of classes based on 
>peak.model.Element, one of which is a primary object that's needed 
>throughout the application.  This object needs to be instantiated and 
>populated as early as possible and made locatable application-wide.  I'm 
>trying to have the instantiation handled by config.provideInstance in a 
>[Provide Utilities] section, then do the population elsewhere (e.g. in an 
>uponAssembly method) before the object is actually used by anything else.

Are you sure you don't want to have a service component that's responsible 
for retrieving the instance?  Like for example, a DM?  The DM can also be 
responsible for loading the object's state, since that's what DM's are for.  :)


>Is this possible using [Provide Utilities], or is this the wrong way to go 
>about it?  If I instead create and offer the object in my top-level 
>application class, utilities instantiated in a [Provide Utilities] section 
>(which are actual components, btw) don't see the "offering" because it's 
>happened too late.

Actually, it's because [Provide Utilities] happens in the configuration 
root, and when created they bind to the root as their parent, so it's 
impossible for something created in [Provide Utilities] to see offerings 
made in your application component.


>   Should I be creating these other "utilities" in some other way as well?

If you need them all to collaborate, then your top-level application class 
is probably the best way.  Ultimately, [Provide Utilities] is there to 
provide system-wide, framework-provided defaults, while still allowing 
local overrides.  I've yet to see an application in my own use that wasn't 
better served by providing utilities from its application class.