You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Tobia Conforto <to...@linux.it> on 2007/10/17 18:20:54 UTC
Calling an InputModule from flowscript
Hello
I'm following the advice Grzegorz gave me about coding my custom
URL-rewriting logic into an input module and using that input module
with the LinkRewriterTransformer, and wherever else I need it.
My input module works well in the sitemap, but I don't seem to be able
to call it from flowscript. The only references I found are this message
from a year ago: http://marc.info/?l=xml-cocoon-users&m=115494972431824
and the file blocks/slide/samples/flow.js They both suggests doing this:
importClass(Packages.org.apache.cocoon.components.modules.input.InputModule);
var foo = cocoon.getComponent(InputModule.ROLE + "Selector").select("foo");
var foobar = foo.getAttribute("bar", null, null);
where "foo" is the input module's name as configured in cocoon.xconf.
But I cannot pass null to my own input module in place of the third
parameter (Map objectModel) because I use that objectModel in my class!
Is this the recommended way of accessing input modules from flowscript?
If so, how do I pass it the objectModel map?
Question #2:
Both the post and the sample fail to call cocoon.releaseComponent() on
the InputModule selector, after calling getComponent() on it. I was
under the impression that you should go to great lengths (try/finally)
to release every Avalon component you acquire. Is it not so?
Tobia
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Calling an InputModule from flowscript
Posted by Tobia Conforto <to...@linux.it>.
I wrote:
> I'm saving the input module into a global flowscript variable, because
> it's supposed to be request-independent.
Nevermind that. I realized I must acquire the input module from the
selector every time, lest I end up with IllegalStateExceptions.
Tobia
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Calling an InputModule from flowscript
Posted by Tobia Conforto <to...@linux.it>.
I wrote:
> I'm saving the input module into a global flowscript variable, because
> it's supposed to be request-independent.
Nevermind that. I realized I must acquire the input module from the
selector every time, lest I end up with IllegalStateExceptions.
Tobia
Re: Calling an InputModule from flowscript
Posted by Tobia Conforto <to...@linux.it>.
Joerg Heinicke wrote:
> Tobia Conforto wrote:
> > But I cannot pass null to my own input module in place of the third
> > parameter (Map objectModel) because I use that objectModel in my
> > class
>
> Another workaround is to create a map in your flowscript with the
> necessary data.
Yes, I had arrived at the same conclusion:
function foo(attr) {
// call an input module that needs access to the request object
var tmp = new java.util.HashMap();
tmp.put('request', cocoon.request);
return fooInputModule.getAttribute(attr, null, tmp);
}
> > the sample fails to call cocoon.releaseComponent() on the
> > InputModule selector, after calling getComponent() on it.
>
> the using code should not be aware of the component's implementation
> details - and that's why it should always release the component.
Here's how I did it, for the archives. By the way, I'm saving the input
module into a global flowscript variable, because it's supposed to be
request-independent. The fake objectModel map, on the other hand, is
created each time in the foo() function.
// in the global scope: get the input module I will call in foo()
var inputModuleSelector = cocoon.getComponent(InputModule.ROLE + "Selector");
try {
var fooInputModule = inputModuleSelector.select("foo");
} finally {
cocoon.releaseComponent(inputModuleSelector);
inputModuleSelector = null;
}
Tobia
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Calling an InputModule from flowscript
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Joerg Heinicke wrote:
> On 10/17/07 12:20 PM, Tobia Conforto wrote:
>
>>
> The object model is indeed not made available in the flow script. You
> can get it from the Avalon context though (code from FOM_Cocoon.java):
> ContextHelper.getObjectModel(avalonContext)
> Unfortuntely, this one is neither available by default. I remember Ard
> posted a solution a while ago to retrieve the Avalon context in a
> hackish way.
Ummm why would you need hackish way if it is readily supplied to any
Contextualizable? InputModule just need to implement Contextualizable, and this
is not a hack. Do I miss something?
> To dev: How is this supposed to be handled? Should access to object
> model be granted? What does the unified object model change about this?
IIRC the decision was that objectModel need not to be present in flowscript; and
in the components it is easily obtainable from context, as you mentioned above.
Vadim
Re: Calling an InputModule from flowscript
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Joerg Heinicke wrote:
> On 10/17/07 12:20 PM, Tobia Conforto wrote:
>
>>
> The object model is indeed not made available in the flow script. You
> can get it from the Avalon context though (code from FOM_Cocoon.java):
> ContextHelper.getObjectModel(avalonContext)
> Unfortuntely, this one is neither available by default. I remember Ard
> posted a solution a while ago to retrieve the Avalon context in a
> hackish way.
Ummm why would you need hackish way if it is readily supplied to any
Contextualizable? InputModule just need to implement Contextualizable, and this
is not a hack. Do I miss something?
> To dev: How is this supposed to be handled? Should access to object
> model be granted? What does the unified object model change about this?
IIRC the decision was that objectModel need not to be present in flowscript; and
in the components it is easily obtainable from context, as you mentioned above.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Calling an InputModule from flowscript
Posted by Joerg Heinicke <jo...@gmx.de>.
On 10/17/07 12:20 PM, Tobia Conforto wrote:
> But I cannot pass null to my own input module in place of the third
> parameter (Map objectModel) because I use that objectModel in my class!
>
> Is this the recommended way of accessing input modules from flowscript?
> If so, how do I pass it the objectModel map?
The object model is indeed not made available in the flow script. You
can get it from the Avalon context though (code from FOM_Cocoon.java):
ContextHelper.getObjectModel(avalonContext)
Unfortuntely, this one is neither available by default. I remember Ard
posted a solution a while ago to retrieve the Avalon context in a
hackish way.
Another workaround is to create a map in your flowscript with the
necessary data.
To dev: How is this supposed to be handled? Should access to object
model be granted? What does the unified object model change about this?
> Question #2:
>
> Both the post and the sample fail to call cocoon.releaseComponent() on
> the InputModule selector, after calling getComponent() on it. I was
> under the impression that you should go to great lengths (try/finally)
> to release every Avalon component you acquire. Is it not so?
That's what you should do. Otherwise life cycle methods like recycle()
don't get called. It depends on your component if it results in an
actual problem. Of course the using code should not be aware of the
component's implementation details - and that's why it should always
release the component.
Joerg
Re: Calling an InputModule from flowscript
Posted by Joerg Heinicke <jo...@gmx.de>.
On 10/17/07 12:20 PM, Tobia Conforto wrote:
> But I cannot pass null to my own input module in place of the third
> parameter (Map objectModel) because I use that objectModel in my class!
>
> Is this the recommended way of accessing input modules from flowscript?
> If so, how do I pass it the objectModel map?
The object model is indeed not made available in the flow script. You
can get it from the Avalon context though (code from FOM_Cocoon.java):
ContextHelper.getObjectModel(avalonContext)
Unfortuntely, this one is neither available by default. I remember Ard
posted a solution a while ago to retrieve the Avalon context in a
hackish way.
Another workaround is to create a map in your flowscript with the
necessary data.
To dev: How is this supposed to be handled? Should access to object
model be granted? What does the unified object model change about this?
> Question #2:
>
> Both the post and the sample fail to call cocoon.releaseComponent() on
> the InputModule selector, after calling getComponent() on it. I was
> under the impression that you should go to great lengths (try/finally)
> to release every Avalon component you acquire. Is it not so?
That's what you should do. Otherwise life cycle methods like recycle()
don't get called. It depends on your component if it results in an
actual problem. Of course the using code should not be aware of the
component's implementation details - and that's why it should always
release the component.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org