cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: JXTG macro calling
Date Sat, 26 Feb 2005 20:48:57 GMT
Leszek Gawron wrote:
> Glen Ezkovich wrote:
>> On Feb 26, 2005, at 7:18 AM, Sylvain Wallez wrote:
>>>> Another question:
>>>> Do you think this syntax would be useful?
>>>> <jx:call macro="${macroName}" p="bar">
>>>>     <content b="${2+3}"/>
>>>> </jx:call>
>>> Do you mean the "p" param as attribute? Yes, it's useful, because IMO 
>>> <jx:withParam> is just as overly verbose as XSLT, to which JXTG is 
>>> supposed to provide a simpler replacement ;-)
>> <jx:withParam> is overly verbose, "p" is not verbose enough. How about 
>> "param". How are multiple parameters to be handled?
> thing is that every instruction is matched to a class. so you have:
> <jx:macro name="something"> <!-- matched to StartDefine -->
>   <jx:parameter name="param1" default="abc"/> <!-- matched to
>                                               StartParameter -->
>   ${param1}
>   <jx:evalBody/>
> </jx:macro>
> then when calling:
> <jx:call name="something"> <!-- matched to StartCall -->
>   <jx:withParam name="param1" value="bcd"/> <!-- matched to
>                                             StartParameterInstance -->
>   <jx:withParam name="param2" value="edc"/>
>   <body>here</body>
> </jx:call>
> We cannot have two instructions bound to the same jx:param or we will 
> again introduce dependencies in Parser.

This constraint is, AFAICS, only dependent on that child instructions 
has access to their ancestor instructions during compile time. This 
means that the diverse param instruction must now which kind of parent 
it has to be able to install itself in its parent in the right way.

Maybe we could have a "parametrizable" inteface for those instructions 
that takes parameters so that the parameter instruction doesn't need to 
know more than that the parent is parametrizable.

It would be even better if we made the refactoring that we discussed in so that 
instructions have access to their children during compilation instead of 
the other way around.


View raw message