Re: accessing sitemap parameters in a flow script
Vadim Gritsenko wrote: Marc Portier wrote: 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: 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
Sylvain Wallez wrote: Marc Portier wrote: Sylvain Wallez wrote: Stefano Mazzocchi wrote: 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 and (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: 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: Sylvain Wallez wrote: Stefano Mazzocchi wrote: 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 and (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: 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: Stefano Mazzocchi wrote: 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 and (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: 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 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
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: 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
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: 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: 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: [...] 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
Andreas Hartmann wrote: Sylvain Wallez wrote: [...] 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
Sylvain Wallez wrote: [...] 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
Andreas Hartmann wrote: Sylvain Wallez wrote: and function foo() { var x = cocoon.parameters["baz"]; } It's even easier: 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
Sylvain Wallez wrote: and function foo() { var x = cocoon.parameters["baz"]; } It's even easier: function foo(bar) { ... } Andreas
Re: accessing sitemap parameters in a flow script
Sylvain Wallez wrote: and function foo() { var x = cocoon.parameters["baz"]; } Easy, no ? Ha. ;-) Added to the Wiki. :-) -- 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: 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
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. 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