Glen Ezkovich wrote:On Feb 26, 2005, at 7:18 AM, Sylvain Wallez wrote:<jx:withParam> is overly verbose, "p" is not verbose enough. How about "param". How are multiple parameters to be handled?
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 ;-)
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 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.
/Daniel
