Re: accessing sitemap parameters in a flow script
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
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
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 Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: accessing sitemap parameters in a flow script
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
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
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
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
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
Re: accessing sitemap parameters in a flow script
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
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 Noelshttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org
Re: accessing sitemap parameters in a flow script
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
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
