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 Sun, 27 Feb 2005 11:21:14 GMT
Sylvain Wallez wrote:

> Daniel Fagerstrom wrote:
>> Sylvain Wallez wrote:

>>> 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:*">

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}"/>

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,, and also important 
standardization activities like modularization of XHTML 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.


View raw message