Return-Path: 
 <dev-return-46723-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 8724 invoked by uid 500); 23 Aug 2003 11:50:24 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 8631 invoked from network); 23 Aug 2003 11:50:22 -0000
Received: from smtp7.wanadoo.fr (HELO mwinf0204.wanadoo.fr) (193.252.22.29)
  by daedalus.apache.org with SMTP; 23 Aug 2003 11:50:22 -0000
Received: from anyware-tech.com (AToulouse-206-1-19-174.w81-53.abo.wanadoo.fr
 [81.53.227.174])
	by mwinf0204.wanadoo.fr (SMTP Server) with ESMTP id C83A7A000063
	for <dev@cocoon.apache.org>; Sat, 23 Aug 2003 13:50:09 +0200 (CEST)
Message-ID: <3F4754F1.6040709@anyware-tech.com>
Date: Sat, 23 Aug 2003 13:50:09 +0200
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.4) Gecko/20030624
X-Accept-Language: fr, en, en-us
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: accessing sitemap parameters in a flow script
References: <16E70CF1-D4C7-11D7-9393-000393D2CB02@apache.org>
 <3F4730CA.4050300@anyware-tech.com> <3F474030.4040902@outerthought.org>
In-Reply-To: <3F474030.4040902@outerthought.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

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