Stephen wrote:
>
> Daniel Frey wrote:
>
>> 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
I think, I have to go through the new tutorials in the HEAD. Are they
already referring to the new concept?
>> 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.
Stephen, I think I am just someone coming from the old non-component idea
having a context object in the application for all "global" stuff. I did not
recognize that exactly this role may be played by the ServiceManager. I am
sorry for my late awareness. Anyway, the Merlin approach saves a lot of
coding!
Daniel
> Cheers, Stephen.
>
>> How do you achieve this usually?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
