Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
<snip/>
Or if you find this counter-intuitive, maybe we can introduce the concept of "element interceptor" which is a macro that gets called when a particular element is encountered. This makes it explicit that some elements will become macro calls.
<jx:intercept element="ft:widget">
<!-- macro body -->
</jx:intercept>
WDYT about requiring the intercepted elements to lie whithin a certain name space? I.e. somthing like:
<jx:intercept ns="http://..../FormsTransformer/1.0";> <!-- macro bodies for forms --> </jx:intercept>
By requiring the macros to lie within predifined namespaces it will be easier to see what is macros and what is not.We can also make it an error to use elements whithin an intercepted name space that doesn't have a macro definition.
Mmmh... I've been thinking also of a "wildcard interceptor", e.g. <jx:intercept element="ns:*"> either to raise an error or to provide some generalized handling of a namespace, or at least those elements in that namespace that aren't explicitely intercepted.
Also, consider this:
<jx:intercept element="html:form"> <!-- same macro as ft:form-template --> </jx:intercept>
<jx:intercept element="html:input"> <!-- same macro as ft:widget --> </jx:intercept>
Now I can turn a raw HTML page into a CForms template by just adding <jx:import uri="..../html-forms.jx"/> at the top of the file. And I certainly don't want to intercept the whole html namespace!
With wildcard interception and the evalBody instruction:
<jx:intercept element="html:*"> <jx:evalBody> </jx:intercept>
there is no problem with intercepting the whole namespace.
But before discussing the details of the solution we should be clear about what problem we try to solve.
I want the CTemplate to be a well behaved combination of XML languages that fullfills the principle of least suprise. And I prefer some verbosity to magic. Unfortunatly it is less clear what this means and how we can achieve it, but there are at least some things we can say.
The CTemplate instructions should live whithin one name space and it should be possible to write a scheme for it. By requiring this it is easy for user to see what is CTemplate instructions and what is not. It also makes it possible to validate the template and an XML editor can be used. It will also be easier to write XSLT that uses the template as input or using other XML aware tools.
From this I'm not particulary happy about "qute" syntax like:
<jx:call macro="${macroName}" p="bar">
<content b="${2+3}"/>
</jx:call>as it makes it less obvious what "p" is, it also makes schemes less strict and complicates the writing of XSLT and the like somewhat.
--- o0o ---
For macros the current JXTG mechanism, where you can make any element a macro is "to much magic" for my taste. It means that if a user imports a macro package that does some "smart" things with elements whithout name spaces their existing template suddenly change meaning in a possibly subtle way. And you cannot see at a glance if an element will be affected by the template generator or not.
Now if we instead have constructions that makes it natural to put all instructions in a macro package within one name space it will be easier for the user to see which instructions that belong together. It will also be easier to write a scheme for the new vocabulary and so on.
A problem is that there not is any standards for puting together schemes for different XML languages to a compound document yet, but there seem to be a lot of activity in the field, http://www.w3.org/2004/CDF/, http://www.thaiopensource.com/relaxng/nrl.html and also important standardization activities like modularization of XHTML http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/ is based on the idea of combining XML languages.
--- o0o ---
So, my main message is that we should take good practices for XML modularization into account when designing the new macro functionality.
And it makes it possible to have schemes for the different name spaces and to make tool support possible.
Can you elaborate on "tools support"? As long as the macro is defined in some way, either on a per-element or on a per-namespace basis, I don't see a real difference.
I mean that it easier to write tools that decide based on the name space what sub tool that should be used. It leads to better modularization and makes it easier to see what belongs together.
/Daniel
