cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Accessing the current CM (was Re: [RT] Flowmaps)
Date Mon, 24 Jun 2002 08:23:49 GMT
Christian Haul wrote:

> Sylvain Wallez wrote:
>
>> Christian Haul wrote:
>>
>>> a) reference to the sitemap's component manager in flow. I have 
>>> found two possibilities, either extending some routines' signatures 
>>> (many modifications) or placing it into the Environment. But I seem 
>>> not to find the place where it   is created. It seems related to 
>>> CocoonComponentManager.getCurrentEnvironment() but  I didn't quite 
>>> understand the mechanics.
>>
>>
>> Look at o.a.c.components.flow.JavaScript.JSCocoon, which makes some 
>> Cocoon objects available to the flow : it already has a 
>> ComponentManager attribute, but doesn't publish it to the script. 
>> This should be a simple matter of adding a jsGet_manager method 
>> (Ovidiu, am I right ?).
>
>
> But - is it the parent ComponentManager or the one used by the 
> sitemap, i.e. are components declared in a sitemap available through 
> that manager? If it is OK to use it, that would be great and I'll try 
> to work  on it tomorrow :-)


It appears to be the CM that declares the interpreter, which is not the 
one you're looking for...

So storing the CM as an attribute of Environment should be the way to 
go, as the current enviromnent is passed to the script upon invocation 
(no need for CocoonComponentSelector).

>>>   Another issue would be components / classes that use a 
>>> ComponentManager without implementing Composable.... but that should 
>>> be OK(?)
>>>   What do you think? Pointers?
>>
>>
>>
>> There are cases where this is needed, but care should be taken to 
>> explicitely release these objects so that they can properly release 
>> the components they obtain from the ComponentManager.
>>
>>> b) to get input modules support into the sitemap, a reference to the 
>>> ComponentManager is needed in several places to pass it to   
>>> MapStackResolver.getResolver. Again, I'm unsure what the best 
>>> strategy would be here. Suggestions?
>>
>>
>> Input modules in the sitemap is on the way on my PC... Little time = 
>> slow speed, but it should be ready this week. Just as you suggest it, 
>> there's an additional "manager" parameter to getResolver(), and 
>> resolvers have a release() method as described above.
>
>
> Good to hear. In the mean time I have spent more time trying to 
> understand the treeprocessor and I may well try to beat you on 
> implementing this ;-) 


Gosh ! Turbo mode on !! ;-)

Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message