Hi there,
Merlin does support two types of contextualization:
- Standard entries. - Custom contexts (safely casted or not).
You have the following under 3.2.5:
- standard entries (urn:avalon:...) - castable context objects - custom context delivery strategies
and under CVS HEAD:
- privaliged context entries ("urn:composition:...)
- avalon independent context objects via constructor
Given I have an application as described in ... where I want assemble a context object, basically a map of keyed objects as described by Stephen (http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] &msgId=624575). The context object has to have an entry for the resource manager and the main frame, both components of other containers.
Context objects are different from service objects in that they don't have structural dependencies.
I would like to add a these two to the context *before* it is passed to subsequent other Avalon components. How is this achieved?
Doing what your describing is in principal possible but would require some heavy-weight manipulation of the object model. The way you archive it is to locate a facility in a parent container (which guarantees it is established in advance) and use this to set the context object entries for sibling component models (i.e. its non-trivial but does provide a very clean object mode for the downstream components).
One way could be to do it in the contextualize method itself. The
application is Contextualizable and adds the two objects to the context.
Here I would have to guarantee that the applications' context method is
called as the really first one of all components.
However, contextualize() is called before service(). And just service() does
deliver access to the other components which I need to set-up the context
(resource manager and main frame).
If your running from CVS head then use the constructor based approach and you eliminate order dependence.
I've the impression I am on the wrong way. Another approach could be that I do not have to code additions/completions of the context object, but to configure it somehow.
Both are feasible. The context based approach will be harder b ut will generate a cleaner object model. The service based approach will be easier to implement in the short term.
Maybe it's even not necessary to have a context object as described first above, as I could configure the resource manager and main frame as singletons, and get access to these two during the service method. I've the impression, that this could fit.
So missing info - need more "bigger picture stuff" to answer this.
Cheers, Stephen.
How do you achieve this usually?
Daniel
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
