cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: JXTG macro calling
Date Sat, 26 Feb 2005 20:59:33 GMT
Daniel Fagerstrom wrote:
> 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.
Thing is that with the macro parameter definition you have
<jx:parameter name="something" default="something"/>
@default being optional

while with paramter instance you have
<jx:parameter name="something" value="something"/>

slightly different semantics.

> 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.
It's easier now as we have instructions independent on the Parser. I'll 
try aiming at that on Monday.

Leszek Gawron                                                 MobileBox                    

View raw message