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
http://marc.theaimsgroup.com/?t=110651778400003&r=1&w=2 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
[EMAIL PROTECTED] http://www.mobilebox.pl
