cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: JXTG macro calling
Date Sun, 27 Feb 2005 09:09:22 GMT
Daniel Fagerstrom wrote:

> Sylvain Wallez wrote:
>> Leszek Gawron wrote:
> <snip/>
>>> what do you think about removing the old syntax in 2.2?
>>> <d p="foo">
>>>     <content b="${1+2}"/>
>>> </d>
>>> For me it is counter-intuitive and leads to accidental mistakes (not 
>>> so easy to find by newbies).
>> -1 on removing this syntax, as it prevents writing things such as the 
>> CForms template language using JXTG (or CTemplate). 
> Seem like a strong enough reason.

Yes ;-)

>> 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 element="html:input">
  <!-- same macro as ft:widget -->

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!

> 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.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message