cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: How to access sitemap parameter within JavaFlow?
Date Thu, 04 Nov 2004 22:08:19 GMT
Michael Gerzabek wrote:

> At 20:49 04.11.2004, you wrote:
>> Hello,
>> I had asked this question in the users list before but got no answer. 
>> So I will try it here. I need to access a sitemap parameter within a 
>> JavaFlow class. Is this possible?
>> <map:call function="myJavaFlowMethod">
>>   <map:parameter name="foo" value="bar"/>
>> </map:call>
>> How can I access the parameter "foo" within the JavaFlow?
> Of course you can do. When you declare a sitemap flow function call 
> like above your flow method must be declared like
> function myJavaFlowMethod( foo ) {
> }
> and a "print( foo );" within this method should show "bar" in your 
> Console.

I strongly suggest you *do not use it this way*, as it is highly 
misleading: <map:parameter> are name/value associations whereas JS 
function parameters are only positional, which means the "foo" you write 
in the function declaration has absolutely no relation with the "foo" in 

Although this isn't a problem with single parameters, this can lead to 
weird bugs with several parameters.

Consider for example:

<map:call function="fun">
  <map:parameter name="foo" value="foo-value"/>
  <map:parameter name="bar" value="bar-value"/>

And "function fun(foo, bar)".

All is well, and this results in calling fun("foo-value", "bar-value").

But one day someone decides to write:
<map:call function="fun">
  <map:parameter name="bar" value="bar-value"/>
  <map:parameter name="foo" value="foo-value"/>

 From a sitemap point of view, this makes no difference, as parameters 
are usually basically a hashmap. But in the particular case of 
flowscript calls, what I consider a hack transform these name/value 
pairs in a list of positional parameters.

So the result is that it calls fun("bar-value", "foo-value"), which is 
really not what you expected...

This behaviour has been there from day one if the flowscript, and it 
took some time to find that it was a problem.

I've been wanting to remove forbid this for a long time, but didn't knew 
how to identify JS functions with parameters, in order to issue a proper 
error message if this buggy construct is used. Looking a bit closer to 
Rhino, I now found it: NativeFunction has a getArity() method which is 
the number of parameters. We could then raise an error if getArity() != 0.

What do people think?

Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message