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