cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: cocoon-template incompatible change
Date Mon, 27 Aug 2007 09:57:17 GMT
Daniel Fagerstrom wrote:
> Leszek Gawron skrev:
>> Grzegorz Kossakowski wrote:
>>> Leszek Gawron pisze:
> ...
>>> I remember that I have read that discussion and I agree that there 
>>> was no clear consensus.
>>> I also remember that there were several folks expressing their 
>>> opinion that jx should as far from
>>> imperative programming language as possible. I second that opinion so 
>>> I'm quite concerned with your
>>> example. It is a programming language.
>>> XSLT lives without such constructs so could you give us a use case 
>>> for this one?
> We should leave the behaviour of JXTG exactly as is. The template 
> framework (yes it actually is designed to be a framework even if we 
> haven't used this) makes it easy to create a new template language. So 
> if you don't like the way JXTG is designed you should design a new 
> template language that has an own generator and an own namespace.

Who did you address this statement to? Me or Grzegorz?

Thing is last refactorings introduced backward incompatibilities. I 
tried to upgrade to next internal release and my webapp went nuts. By 
saying "we should leave the behaviour as is" you mean we should keep 
those incompatible changes?

>> I never used one like this :) Still the problem remains as not every 
>> cocoon user knows xslt and the example I gave would feel natural for him.
>>> Nevertheless, we need to fix scoping now so we really need to gather 
>>> some consensus when new local
>>> context should be established.
>> My proposal is:
>> No new scope for:
>> - any plain xml element (namespaced or not). by plain I mean not macro 
>> invocation.
>> - jx:import without context set
>> - formatting instructions (jx:formatDate, jx:formatNumber)
>> New strict scope for (strict scope - no inheritance, still all 
>> cocoon.* should be available):
>> - jx:call (same for <macroName/> invocation)
>> - jx:import context="${bean}"
>> - jx:macro
>> New inherited scope for:
>> - jx:forEach
>> - jx:if ??
>> - jx:choose/jx:when/jx:otherwise ??
>> last two (jx:if, jx:choose) are currently NOT scoped.
> We had a discussion about what to have in a new CTemplate language, see 
> Maybe it is 
> time to review if the ideas there still holds and then continue the work 
> on creating a CTemplate language.

Do you bookmark these? I never seem to be able to find the right thread 
to reference and you're always shootings with URLs. :)

Leszek Gawron               
CTO at MobileBox Ltd.

View raw message