[TransWarp] Domain model objects as utilities?
Phillip J. Eby
pje at telecommunity.com
Fri Oct 17 17:34:57 EDT 2003
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.
More information about the PEAK