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 <map:parameter>.

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"/>
</map:call>

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"/>
</map:call>

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
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



Reply via email to