You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Steven Noels <st...@outerthought.org> on 2003/08/15 17:44:32 UTC
accessing sitemap parameters in a flow script
Hi all,
I guess the title says about all. ;-)
I want to dynamically load a Woody form definition, its name being based
on the URI invoking the flow function. What's the easiest way to do
this? I saw some very similar questions pass by, but I fail to find out
whether this is already implemented, and if so, whether one can access
the parameter by name, instead of depending on the sequence of attributes.
Thanks,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: accessing sitemap parameters in a flow script
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Sylvain Wallez wrote:
> var x = cocoon.parameters["baz"];
Ooops. Should be "var x = cocoon.parameters["bar"];" of course.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: accessing sitemap parameters in a flow script
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
> Marc Portier wrote:
>
> <snip/>
>
>>> There's already a "parameters" property in the "cocoon" object.
>>>
>>> We can have :
>>> function whatever() {
>>> doSomething(cocoon.parameters.x, cocoon.parameters.y);
>>> }
>>
>>
>
> And nobody still answered the question: why passing of parameters into
> the function
>
> function whatever(x, y, z)
>
> is required and can not be removed? Let's remove this and move along.
> cocoon.parameters is much better and has no place for confusion.
+1. But this creates a back incompatibility with the released 2.1 version...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: accessing sitemap parameters in a flow script
Posted by Vadim Gritsenko <va...@verizon.net>.
Marc Portier wrote:
<snip/>
>> There's already a "parameters" property in the "cocoon" object.
>>
>> We can have :
>> function whatever() {
>> doSomething(cocoon.parameters.x, cocoon.parameters.y);
>> }
>
And nobody still answered the question: why passing of parameters into
the function
function whatever(x, y, z)
is required and can not be removed? Let's remove this and move along.
cocoon.parameters is much better and has no place for confusion.
Vadim
Re: accessing sitemap parameters in a flow script
Posted by Marc Portier <mp...@outerthought.org>.
Sylvain Wallez wrote:
> Marc Portier wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Stefano Mazzocchi wrote:
>>
>>
>> <snip />
>>
>>>> If we match by variable name rather than by position, it would work
>>>> anyway.
>>>>
>>>> ... but I have the feeling I'm missing a big point here.
>>>
>>>
>>>
>>> Yeah : the point is that parameters are passed as Object[] to a JS
>>> function. The names given both in the sitemap parameters and the JS
>>> function parameters are therefore unusable for parameter passing.
>>> Only their position counts. See
>>> FOM_JavaScriptInterpreter.callFunction (line 553) : "funArgs" is a
>>> Object[].
>>>
>>> Sylvain
>>
>>
>>
>> Yes,
>>
>> and it's quite logic since js doesn't have the notion of named
>> argument-passing in the first place:
>>
>> what I mean is that you can't have a
>> function whatever( x, y) {
>> return x - y;
>> }
>>
>> and then call that with:
>>
>> someresult = whatever(y= 4, x= 5)
>>
>> while naming the arguments by how they are declared in the function,
>> and not deducing their role from their position
>>
>> there are some scripting languages that do this IIRC, but not js
>>
>> Going back to the origin of the discussion: we are calling this NOT
>> from another js code portion, but from our beloved sitemap and there
>> it is hard to see functional difference between
>>
>> <map:call function="whatever">
>> <map:parameter name="x" value="5" />
>> <map:parameter name="y" value="4" />
>> </map:call>
>>
>> and
>>
>> <map:call function="whatever">
>> <map:parameter name="y" value="4" />
>> <map:parameter name="x" value="5" />
>> </map:call>
>>
>> (although in strict XML infoset speak I guess there is a difference,
>> no? (order of elements is important)
>>
>> maybe it is just that other spots in the sitemap made us custom to
>> ignoring this fact?)
>>
>> One way to go about balancing of the technics and the sociologics in
>> this could be to pass in an argument-object-map rather then multiple
>> arguments:
>>
>> so thinking about this:
>>
>> function whatever(args) {
>> dosomething(args.x);
>> dosomething(args.y);
>> }
>>
>> we get a more natural comparison between:
>>
>> someresult = whatever({y: 5, x: 4})
>>
>> and:
>>
>> <map:call function="whatever">
>> <map:arguments>
>> <map:parameter name="y" value="5" />
>> <map:parameter name="x" value="4" />
>> </map:arguments>
>> </map:call>
>>
>>
>> which the famous line 553 Sylvain just mentioned could easily map onto
>> a single element Object[] to pass...
>>
>>
>> but all I did now is made some stuff more explicit...
>>
>> what do you guys think, some direction for a suitable compromise?
>
>
>
> There's already a "parameters" property in the "cocoon" object.
>
> We can have :
> function whatever() {
> doSomething(cocoon.parameters.x, cocoon.parameters.y);
> }
>
> Sylvain
>
yep,
that crossed my mind,
but that knowledge didn't seem to stop the discussion in this
thread before :-)
so I was just going for a more explicit approach that maybe
did.... I have to agree that it adds to no functionality
it could make things however less arbitrary/hidden
cocoon.parameter?, or did we use cocoon.function-arguments
or was it on another object in the FOM? let's send a mail!
Subject: Who remembers actively where those damn parameters are?
IMHO at this stage the thread is not any more about 'what can be
functionally done' it is about 'how can we make it self
describing' so we don't end up explaining this to people all over
again?
in any case, it was just a proposal, and if nothing else, I hope
I pointed out the source-mismatch in this.
regards,
-marc=
PS: I'ld like to understand how cocoon.parameters gets to exist
since that is maybe something I coud use inside Apples as well
(you know by heart where to look?)
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: accessing sitemap parameters in a flow script
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Marc Portier wrote:
> Sylvain Wallez wrote:
>
>> Stefano Mazzocchi wrote:
>
> <snip />
>
>>> If we match by variable name rather than by position, it would work
>>> anyway.
>>>
>>> ... but I have the feeling I'm missing a big point here.
>>
>>
>> Yeah : the point is that parameters are passed as Object[] to a JS
>> function. The names given both in the sitemap parameters and the JS
>> function parameters are therefore unusable for parameter passing.
>> Only their position counts. See
>> FOM_JavaScriptInterpreter.callFunction (line 553) : "funArgs" is a
>> Object[].
>>
>> Sylvain
>
>
> Yes,
>
> and it's quite logic since js doesn't have the notion of named
> argument-passing in the first place:
>
> what I mean is that you can't have a
> function whatever( x, y) {
> return x - y;
> }
>
> and then call that with:
>
> someresult = whatever(y= 4, x= 5)
>
> while naming the arguments by how they are declared in the function,
> and not deducing their role from their position
>
> there are some scripting languages that do this IIRC, but not js
>
> Going back to the origin of the discussion: we are calling this NOT
> from another js code portion, but from our beloved sitemap and there
> it is hard to see functional difference between
>
> <map:call function="whatever">
> <map:parameter name="x" value="5" />
> <map:parameter name="y" value="4" />
> </map:call>
>
> and
>
> <map:call function="whatever">
> <map:parameter name="y" value="4" />
> <map:parameter name="x" value="5" />
> </map:call>
>
> (although in strict XML infoset speak I guess there is a difference,
> no? (order of elements is important)
>
> maybe it is just that other spots in the sitemap made us custom to
> ignoring this fact?)
>
> One way to go about balancing of the technics and the sociologics in
> this could be to pass in an argument-object-map rather then multiple
> arguments:
>
> so thinking about this:
>
> function whatever(args) {
> dosomething(args.x);
> dosomething(args.y);
> }
>
> we get a more natural comparison between:
>
> someresult = whatever({y: 5, x: 4})
>
> and:
>
> <map:call function="whatever">
> <map:arguments>
> <map:parameter name="y" value="5" />
> <map:parameter name="x" value="4" />
> </map:arguments>
> </map:call>
>
>
> which the famous line 553 Sylvain just mentioned could easily map onto
> a single element Object[] to pass...
>
>
> but all I did now is made some stuff more explicit...
>
> what do you guys think, some direction for a suitable compromise?
There's already a "parameters" property in the "cocoon" object.
We can have :
function whatever() {
doSomething(cocoon.parameters.x, cocoon.parameters.y);
}
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: accessing sitemap parameters in a flow script
Posted by Marc Portier <mp...@outerthought.org>.
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>>
<snip />
>>
>> If we match by variable name rather than by position, it would work
>> anyway.
>>
>> ... but I have the feeling I'm missing a big point here.
>
>
>
> Yeah : the point is that parameters are passed as Object[] to a JS
> function. The names given both in the sitemap parameters and the JS
> function parameters are therefore unusable for parameter passing. Only
> their position counts. See FOM_JavaScriptInterpreter.callFunction (line
> 553) : "funArgs" is a Object[].
>
> Sylvain
>
Yes,
and it's quite logic since js doesn't have the notion of named
argument-passing in the first place:
what I mean is that you can't have a
function whatever( x, y) {
return x - y;
}
and then call that with:
someresult = whatever(y= 4, x= 5)
while naming the arguments by how they are declared in the
function, and not deducing their role from their position
there are some scripting languages that do this IIRC, but not js
Going back to the origin of the discussion: we are calling this
NOT from another js code portion, but from our beloved sitemap
and there it is hard to see functional difference between
<map:call function="whatever">
<map:parameter name="x" value="5" />
<map:parameter name="y" value="4" />
</map:call>
and
<map:call function="whatever">
<map:parameter name="y" value="4" />
<map:parameter name="x" value="5" />
</map:call>
(although in strict XML infoset speak I guess there is a
difference, no? (order of elements is important)
maybe it is just that other spots in the sitemap made us custom
to ignoring this fact?)
One way to go about balancing of the technics and the sociologics
in this could be to pass in an argument-object-map rather then
multiple arguments:
so thinking about this:
function whatever(args) {
dosomething(args.x);
dosomething(args.y);
}
we get a more natural comparison between:
someresult = whatever({y: 5, x: 4})
and:
<map:call function="whatever">
<map:arguments>
<map:parameter name="y" value="5" />
<map:parameter name="x" value="4" />
</map:arguments>
</map:call>
which the famous line 553 Sylvain just mentioned could easily map
onto a single element Object[] to pass...
but all I did now is made some stuff more explicit...
what do you guys think, some direction for a suitable compromise?
-marc=
PS: I felt this issue also while doing my initial research in the
Apples block. I then suggested (a.o.t.) to change the List
params argument of the Interpreter.callFunction and
Interpreter.handleContinuation to something more like a Map or
straight Parameters object
sounds now like even the js implementation could benefit from the
change, purely on how sitemap-savvy people perceive this naming
over ordering thing?
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: accessing sitemap parameters in a flow script
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>
> On Wednesday, Aug 20, 2003, at 11:27 Europe/Rome, Sylvain Wallez wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>> On Friday, Aug 15, 2003, at 23:49 Europe/Rome, Sylvain Wallez wrote:
>>
>>
>> <snip/>
>>
>>>> And this really demonstrates how dangerous can be this translation
>>>> to positional parameter ;-)
>>>
>>>
>>>
>>> why don't we fix this, then?
>>
>>
>> Well, positional parameters have been there since day one in
>> FlowScript, and many of the existing flows, including Cocoon's own
>> flow libraries such as XMLForm and Woody rely on this feature.
>
>
> Can you explain how? I've personally used flow without thinking of
> variable positioning, it just happened to be ordered correctly. I can
> easily see people pissed off by discoverying this "feature" after
> hours of cursing!
And this is what will happen if they put their variables with the right
name but in the wrong order !
>> So we can't remove it abruptly.
>
>
> If we match by variable name rather than by position, it would work
> anyway.
>
> ... but I have the feeling I'm missing a big point here.
Yeah : the point is that parameters are passed as Object[] to a JS
function. The names given both in the sitemap parameters and the JS
function parameters are therefore unusable for parameter passing. Only
their position counts. See FOM_JavaScriptInterpreter.callFunction (line
553) : "funArgs" is a Object[].
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: accessing sitemap parameters in a flow script
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Aug 20, 2003, at 11:27 Europe/Rome, Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>> On Friday, Aug 15, 2003, at 23:49 Europe/Rome, Sylvain Wallez wrote:
>
> <snip/>
>
>>> And this really demonstrates how dangerous can be this translation
>>> to positional parameter ;-)
>>
>>
>> why don't we fix this, then?
>
>
> Well, positional parameters have been there since day one in
> FlowScript, and many of the existing flows, including Cocoon's own
> flow libraries such as XMLForm and Woody rely on this feature.
Can you explain how? I've personally used flow without thinking of
variable positioning, it just happened to be ordered correctly. I can
easily see people pissed off by discoverying this "feature" after hours
of cursing!
> So we can't remove it abruptly.
If we match by variable name rather than by position, it would work
anyway.
... but I have the feeling I'm missing a big point here.
> But we could deprecate it, meaning keep it functional to avoid
> breaking things, but remove any reference to this feature in the code
> and the docs.
--
Stefano.
Re: accessing sitemap parameters in a flow script
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
> On Friday, Aug 15, 2003, at 23:49 Europe/Rome, Sylvain Wallez wrote:
<snip/>
>> And this really demonstrates how dangerous can be this translation to
>> positional parameter ;-)
>
>
> why don't we fix this, then?
Well, positional parameters have been there since day one in FlowScript,
and many of the existing flows, including Cocoon's own flow libraries
such as XMLForm and Woody rely on this feature.
So we can't remove it abruptly. But we could deprecate it, meaning keep
it functional to avoid breaking things, but remove any reference to this
feature in the code and the docs.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: accessing sitemap parameters in a flow script
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Aug 15, 2003, at 23:49 Europe/Rome, Sylvain Wallez wrote:
> Andreas Hartmann wrote:
>
>> Sylvain Wallez wrote:
>>
>> [...]
>>
>>>> <map:call function="foo">
>>>> <map:parameter name="bar" value="baz"/>
>>>> </map:call>
>>>>
>>>> function foo(bar) {
>>>> ...
>>>> }
>>>
>>>
>>> This syntax turns named parameters in the sitemap into positional
>>> parameters of the function. This is likely to cause very confusing
>>> bugs when someone considers that sitemap parameters are name
>>> value-pairs, which they basically are. Note also that it's the
>>> *only* place in the sitemap where parameter order is important.
>>>
>>> IMO, the use of cocoon.parameters should be encouraged. Furthermore,
>>> cocoon.parameters is the only way to pass sitemap parameters to a
>>> continuation.
>>
>>
>> Thanks, that's good to know!
>> I really thought it was a name-value mapping.
>
>
> And this really demonstrates how dangerous can be this translation to
> positional parameter ;-)
why don't we fix this, then?
--
Stefano.
Re: accessing sitemap parameters in a flow script
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Andreas Hartmann wrote:
> Sylvain Wallez wrote:
>
> [...]
>
>>> <map:call function="foo">
>>> <map:parameter name="bar" value="baz"/>
>>> </map:call>
>>>
>>> function foo(bar) {
>>> ...
>>> }
>>
>>
>> This syntax turns named parameters in the sitemap into positional
>> parameters of the function. This is likely to cause very confusing
>> bugs when someone considers that sitemap parameters are name
>> value-pairs, which they basically are. Note also that it's the *only*
>> place in the sitemap where parameter order is important.
>>
>> IMO, the use of cocoon.parameters should be encouraged. Furthermore,
>> cocoon.parameters is the only way to pass sitemap parameters to a
>> continuation.
>
>
> Thanks, that's good to know!
> I really thought it was a name-value mapping.
And this really demonstrates how dangerous can be this translation to
positional parameter ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: accessing sitemap parameters in a flow script
Posted by Andreas Hartmann <an...@apache.org>.
Sylvain Wallez wrote:
[...]
>> <map:call function="foo">
>> <map:parameter name="bar" value="baz"/>
>> </map:call>
>>
>> function foo(bar) {
>> ...
>> }
>
> This syntax turns named parameters in the sitemap into positional
> parameters of the function. This is likely to cause very confusing bugs
> when someone considers that sitemap parameters are name value-pairs,
> which they basically are. Note also that it's the *only* place in the
> sitemap where parameter order is important.
>
> IMO, the use of cocoon.parameters should be encouraged. Furthermore,
> cocoon.parameters is the only way to pass sitemap parameters to a
> continuation.
Thanks, that's good to know!
I really thought it was a name-value mapping.
Andreas
Re: accessing sitemap parameters in a flow script
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Andreas Hartmann wrote:
> Sylvain Wallez wrote:
>
>> <map:call function="foo">
>> <map:parameter name="bar" value="baz"/>
>> </map:call>
>>
>> and
>>
>> function foo() {
>> var x = cocoon.parameters["baz"];
>> }
>
>
> It's even easier:
>
> <map:call function="foo">
> <map:parameter name="bar" value="baz"/>
> </map:call>
>
> function foo(bar) {
> ...
> }
This syntax turns named parameters in the sitemap into positional
parameters of the function. This is likely to cause very confusing bugs
when someone considers that sitemap parameters are name value-pairs,
which they basically are. Note also that it's the *only* place in the
sitemap where parameter order is important.
IMO, the use of cocoon.parameters should be encouraged. Furthermore,
cocoon.parameters is the only way to pass sitemap parameters to a
continuation.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: accessing sitemap parameters in a flow script
Posted by Andreas Hartmann <an...@apache.org>.
Sylvain Wallez wrote:
> <map:call function="foo">
> <map:parameter name="bar" value="baz"/>
> </map:call>
>
> and
>
> function foo() {
> var x = cocoon.parameters["baz"];
> }
It's even easier:
<map:call function="foo">
<map:parameter name="bar" value="baz"/>
</map:call>
function foo(bar) {
...
}
Andreas
Re: accessing sitemap parameters in a flow script
Posted by Steven Noels <st...@outerthought.org>.
Sylvain Wallez wrote:
> <map:call function="foo">
> <map:parameter name="bar" value="baz"/>
> </map:call>
>
> and
>
> function foo() {
> var x = cocoon.parameters["baz"];
> }
>
> Easy, no ?
Ha. ;-)
Added to the Wiki. :-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: accessing sitemap parameters in a flow script
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Steven Noels wrote:
> Hi all,
>
> I guess the title says about all. ;-)
>
> I want to dynamically load a Woody form definition, its name being
> based on the URI invoking the flow function. What's the easiest way to
> do this? I saw some very similar questions pass by, but I fail to find
> out whether this is already implemented, and if so, whether one can
> access the parameter by name, instead of depending on the sequence of
> attributes.
<map:call function="foo">
<map:parameter name="bar" value="baz"/>
</map:call>
and
function foo() {
var x = cocoon.parameters["baz"];
}
Easy, no ?
;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com