Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <46D29FFD.9070705@mobilebox.pl>
Date: Mon, 27 Aug 2007 11:57:17 +0200
From: Leszek Gawron <lgawron@mobilebox.pl>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: cocoon-template incompatible change
References: <46CEF3FE.2080701@mobilebox.pl> <46CEFF27.6040602@tuffmail.com>
 <46D05EC6.9010604@mobilebox.pl> <46D06D26.50600@apache.org>
 <46D2877E.3070807@mobilebox.pl> <46D28EAC.9000400@apache.org>
 <46D29130.9070105@mobilebox.pl> <46D294EF.3040405@apache.org>
 <46D2980A.8020808@mobilebox.pl> <46D29D49.6080904@nada.kth.se>
In-Reply-To: <46D29D49.6080904@nada.kth.se>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

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 
> http://marc.info/?l=xml-cocoon-dev&m=110942299719102&w=2. 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                         http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.