You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by BURGHARD Éric <er...@systheo.com> on 2005/01/20 15:07:25 UTC
xml languages
hi everybody,
I'm a little disapointed by all theses xml languages we can found around
which nearly all do the same things.
1) Last time i wanted to construct a project with maven and i found jelly.
it had a rich tag library, handle jexl expressions, and can handle xpath
through tag's libraries. But, as maven users, you all know that.
So my question (naïve), is why not using jelly (jelly generator) instead of
redo the work with jxtemplate. I wonder why using ant mutant anteater too,
because IMHO testing with ant+jelly+junit+http(client) is much more
powerfull (multipart post, upload file, ...). And we could certainly define
a new tag library (macros) and run the anteater scripts "as is" with jelly.
2) I play last time with saxon8 and xpath/xslt2.0. I found that it looks
much more like a programming language than ever (well it's still xml). I
like the simplified stylesheet syntax, which allow you to mix the document
and the stylesheet into one document (like jx).
So is there any plan to add an xslt2.0 generator. Think about a generator
which add some context variables (like $cocoon), or give access to
protocols (like cocoon:/) inside in your template.
these 2 candidates have a bigger audience than jxtemplate.
just some thought
Re: Variable Asignment in JXTG (was: xml languages)
Posted by BURGHARD Éric <er...@systheo.com>.
Daniel Fagerstrom wrote:
> <jx:forEach items="#{$node[@path]}">
> ...
>
> But it wasn't clear to me what the use case does.
>
>> I also had several
>> cases where I wanted the numbering to be consistent across several
>> forEach calls and also had to implement hacks.
>
Couldn't say better :-). That's a good abstract of what this hack is
supposed to do.
> Can possibly be done by adding count($node[@path]) to the counter.
>
I cut off too many as well as too few lines from my "real" use case :-)
sorry. But no i can't do that. ;-(
> I'm certain that you can find cases that not are solved with this. The
> question is how much of a programming language we want our template
> language to be, and my opinion is that we should contain as little
> "programming" constructs as possible while still being usable as a view.
> We must of course discuss where we should draw the line. But I would go
> for less. WDOT?
>
I think that jx:template is already a full featured programming language
(turing's machine). Anyway, what we can't do natively, we can do it with
hacks. For me everything that could potentialy minimizing the need of such
hacks is good for the "language".
>>> Another possibility is to let set asign the value to the first
>>> variable binding with the same name that it finds when the stack is
>>> searched, instead of creating a new binding at the top of the stack if
>>> the name doesn't exist on the top of the stack. If we go for this we
>>> need two constructions one that declare and possibly gives an intial
>>> value to a variable in the current context and one that binds the
>>> uppermost occurance of the name, a jx:declare and a jx:set e.g.
>>>
>>> Also we would need to change the API and behaviour of
>>> ExpressionContext so that we both have a declare and a set method.
>>> This should probably be done anyway.
>>>
>>> WDYT?
>>>
>>> /Daniel
>>>
>> I prefer the second solution. The only thing to make the use case work
>> is the ability to set the variable without implicit declaration.
>>
+1. because i don't feel like facing a functionnal programming language when
i look to jxtemplate, and adding such a declaration could be confusing for
the hardcore ones.
>> One more question: should jx:set automatically declare if there is no
>> previous declaration? I think yes.
>>
>> When we reach an agreement I can implement it as it looks quite
>> straightforward.
>
> Thinking a little bit more about it, we can't change the current
> behavoiur of jx:set in the indicated dirresction, it will break peoples
> templates and we don't want that.
>
True ! I see 2 solutions:
- adding an 1.0 compatibility argument to jxtg 2.0
- add the new construction and deprecate jx:set
> I suggest that (given that we decide to go the "assignment" way, that we
> introduce two new constructions: jx:define (or declare, let, variable
> etc) and jx:assign. jx:define introduces a new variable in the current
> context and give it an initial value, it is an error to use jx:define
> for the same variable two times in the same context. jx:asign assigns
> the value of a previous declared variable and it is an error to assign
> an undefined variable. I prefer to not have any implicit declaration of
> undefined variable from jx:assign.
>
> From an implementation POV the ExpressionContext must be extended with
> new methods for assignment and declaration of variables as the put
> instruction supports the current jx:set behaviour.
>
Great (Y).
> /Daniel
Variable Asignment in JXTG (was: xml languages)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>> BURGHARD Éric wrote:
<snip/>
>>> Variable nature and scope (kind of non-mutable that you can overwrite
>>> ?),
>>> but someone could tell me this a feature :-). Perhaps i've miss
>>> something,
>>> but look what i need to do to retrieve a value incremented inside a
>>> forEach
>>> loop:
>>>
>>> <jx:set var="globalvars" value="${java.util.HashMap(5)}"/>
>>> <jx:set var="dummy" value="${globalvars.put('a_count', 0)}"/>
>>> ...
>>> <jx:set var="a_count" value="${globalvars.a_count}"/>
>>> <jx:forEach begin="1" end="3" varStatus="i">
>>> ...
>>> <jx:if test="#{$node/@path != ''}">
>>> ...
>>> <jx:set var="a_count" value="${a_count+1}"/>
>>> <jx:set var="dummy" value="${globalvars.put('a_count',
>>> a_count)}"/>
>>> </jx:if>
>>> </jx:forEach>
>>>
>>> <jx:out>this is my count: ${globalvars.a_count}</jx:out>
>>>
>>> It would be easiest (and efficient) to do
>>> <jx:set var="a_count" value="0"/>
>>> <jx:forEach begin="1" end="3" varStatus="i">
>>> ...
>>> <jx:if test="#{$node/@path != ''}">
>>> ...
>>> <jx:set var="a_count" value="${a_count+1}"/>
>>> </jx:forEach>
>>>
>>> <jx:out>this is my count: ${a_count}</jx:out>
>>>
>>> the fact that "set" make always a "new define" is quite annoying at
>>> first
>>> glance (functional programming ?).
>>
>> The expression context is implemented as a stack of maps and the put
>> instruction on the context is a put on the top map. ForEach is
>> implemented in such way that the loop is performed in a local map that
>> is pushed on stack before the loop and poped afterwards. The set
>> instruction will do a put on the top map and will disapear afterwards
>> because of that.
>>
>> Ok, that explains the behaviour, the question is what we should do
>> about the, admitingly, weird behaviour.
>>
>> One possibilty would be to decide that we want JXTG to be more like a
>> functional language. In that case we should deprecate jx:set and
>> introduce a jx:let instead that just gives a local name for an
>> expression and that gives an exception if you try to set the
>> "variable" to a new value. I think I would prefer this behaviour as I
>> would prefer having a template language without side effects.
>
> This proposal does not solve the use case provided.
Could possibly be done with:
<jx:forEach items="#{$node[@path]}">
...
But it wasn't clear to me what the use case does.
> I also had several
> cases where I wanted the numbering to be consistent across several
> forEach calls and also had to implement hacks.
Can possibly be done by adding count($node[@path]) to the counter.
I'm certain that you can find cases that not are solved with this. The
question is how much of a programming language we want our template
language to be, and my opinion is that we should contain as little
"programming" constructs as possible while still being usable as a view.
We must of course discuss where we should draw the line. But I would go
for less. WDOT?
>> Another possibility is to let set asign the value to the first
>> variable binding with the same name that it finds when the stack is
>> searched, instead of creating a new binding at the top of the stack if
>> the name doesn't exist on the top of the stack. If we go for this we
>> need two constructions one that declare and possibly gives an intial
>> value to a variable in the current context and one that binds the
>> uppermost occurance of the name, a jx:declare and a jx:set e.g.
>>
>> Also we would need to change the API and behaviour of
>> ExpressionContext so that we both have a declare and a set method.
>> This should probably be done anyway.
>>
>> WDYT?
>>
>> /Daniel
>>
> I prefer the second solution. The only thing to make the use case work
> is the ability to set the variable without implicit declaration.
>
> One more question: should jx:set automatically declare if there is no
> previous declaration? I think yes.
>
> When we reach an agreement I can implement it as it looks quite
> straightforward.
Thinking a little bit more about it, we can't change the current
behavoiur of jx:set in the indicated dirresction, it will break peoples
templates and we don't want that.
I suggest that (given that we decide to go the "assignment" way, that we
introduce two new constructions: jx:define (or declare, let, variable
etc) and jx:assign. jx:define introduces a new variable in the current
context and give it an initial value, it is an error to use jx:define
for the same variable two times in the same context. jx:asign assigns
the value of a previous declared variable and it is an error to assign
an undefined variable. I prefer to not have any implicit declaration of
undefined variable from jx:assign.
From an implementation POV the ExpressionContext must be extended with
new methods for assignment and declaration of variables as the put
instruction supports the current jx:set behaviour.
/Daniel
Re: xml languages
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> BURGHARD Éric wrote:
>
>>> I'm working on refactoring JXTG so that it will be easier to support and
>>> develop. I'm aware about that you have access the request object etc
>>
>>
>> Great ! Don't know if i can help (time), but if you have a road map or
>> something like that, i would be happy to contribute.
>
>
> I will write a roadmap. All contributions are welcome, a simple but
> important contribution is to start using the refactored JXTG instead of
> the original and report or even better send patches for the bugs.
>
>>> differently depending on if you are using flow or not and also that the
>>> eval tag is less well designed. What more weird behaviours are you
>>> thinking of?
>>
>>
>> Variable nature and scope (kind of non-mutable that you can overwrite ?),
>> but someone could tell me this a feature :-). Perhaps i've miss
>> something,
>> but look what i need to do to retrieve a value incremented inside a
>> forEach
>> loop:
>>
>> <jx:set var="globalvars" value="${java.util.HashMap(5)}"/>
>> <jx:set var="dummy" value="${globalvars.put('a_count', 0)}"/>
>> ...
>> <jx:set var="a_count" value="${globalvars.a_count}"/>
>> <jx:forEach begin="1" end="3" varStatus="i">
>> ...
>> <jx:if test="#{$node/@path != ''}">
>> ...
>> <jx:set var="a_count" value="${a_count+1}"/>
>> <jx:set var="dummy" value="${globalvars.put('a_count', a_count)}"/>
>> </jx:if>
>> </jx:forEach>
>>
>> <jx:out>this is my count: ${globalvars.a_count}</jx:out>
>>
>> It would be easiest (and efficient) to do
>> <jx:set var="a_count" value="0"/>
>> <jx:forEach begin="1" end="3" varStatus="i">
>> ...
>> <jx:if test="#{$node/@path != ''}">
>> ...
>> <jx:set var="a_count" value="${a_count+1}"/>
>> </jx:forEach>
>>
>> <jx:out>this is my count: ${a_count}</jx:out>
>>
>> the fact that "set" make always a "new define" is quite annoying at first
>> glance (functional programming ?).
>
>
> The expression context is implemented as a stack of maps and the put
> instruction on the context is a put on the top map. ForEach is
> implemented in such way that the loop is performed in a local map that
> is pushed on stack before the loop and poped afterwards. The set
> instruction will do a put on the top map and will disapear afterwards
> because of that.
>
> Ok, that explains the behaviour, the question is what we should do about
> the, admitingly, weird behaviour.
>
> One possibilty would be to decide that we want JXTG to be more like a
> functional language. In that case we should deprecate jx:set and
> introduce a jx:let instead that just gives a local name for an
> expression and that gives an exception if you try to set the "variable"
> to a new value. I think I would prefer this behaviour as I would prefer
> having a template language without side effects.
This proposal does not solve the use case provided. I also had several
cases where I wanted the numbering to be consistent across several
forEach calls and also had to implement hacks.
>
> Another possibility is to let set asign the value to the first variable
> binding with the same name that it finds when the stack is searched,
> instead of creating a new binding at the top of the stack if the name
> doesn't exist on the top of the stack. If we go for this we need two
> constructions one that declare and possibly gives an intial value to a
> variable in the current context and one that binds the uppermost
> occurance of the name, a jx:declare and a jx:set e.g.
>
> Also we would need to change the API and behaviour of ExpressionContext
> so that we both have a declare and a set method. This should probably be
> done anyway.
>
> WDYT?
>
> /Daniel
>
I prefer the second solution. The only thing to make the use case work
is the ability to set the variable without implicit declaration.
One more question: should jx:set automatically declare if there is no
previous declaration? I think yes.
When we reach an agreement I can implement it as it looks quite
straightforward.
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: xml languages
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Jan 24, 2005, at 3:10 PM, Daniel Fagerstrom wrote:
> Vadim Gritsenko wrote:
>> Daniel Fagerstrom wrote:
>>>
>>> Ok, that explains the behaviour, the question is what we should do
>>> about the, admitingly, weird behaviour.
>> How it is weird - it's same as in xslt.
>
> Not exactly, while xsl:variable is like a final declaration in Java,
> jx:set is an asignment and can be used for e.g. counting things in a
> forEach. The "weird" part is that you can't define a global variable
> and use it as a counter in a sequence of loops as it will be redifined
> in the current context if it does not exist there. See Eric Burghard's
> example earlier in this thread.
>
>>> One possibilty would be to decide that we want JXTG to be more like
>>> a functional language.
>> +1
>>> In that case we should deprecate jx:set and introduce a jx:let
>>> instead that just gives a local name for an expression and that
>>> gives an exception if you try to set the "variable" to a new value.
>> Not sure this is necessary.
>>> I think I would prefer this behaviour as I would prefer having a
>>> template language without side effects.
>> +100
>>> Another possibility is to let set asign the value to the first
>>> variable binding with the same name that it finds when the stack is
>>> searched,
>> -1. Don't think this is a possibility; as noted above, templates
>> should be side effect free.
>
> Glad that you agree :) Eric and Leszek are not convinced at all and
> want real assignment.
>
> I would also prefer complete freeness of side effects, but that would
> require us to write an own expression language as both Jexl and JXPath
> allows for calling put methods etc.
While this is true these are the expression languages used within the
template language. The problem is that there is noway in Java to
prevent a method invocation having side effects. If we were to use
reflection to check whether a method returned a value we still couldn't
be sure that it did not have any side effects. If you want to prevent
side effects you would need to allow JXTG to only accept read only maps
of strings and other maps. I'm pretty sure this would cause a riot.
All we can insure is that nothing within the jx namespace has any side
effects.
>
> There is the same problem with extension functions in XSLT, but of
> some reason people seem much more interested in using side effects in
> JXTG than in XSLT.
Side effects are easy, even though evil. There is nothing you can do
with side effects that you can't do without them. It's some times just
simpler. Recursion fries minds. Maybe the reason people are interested
in side effects in JXTG is that they don't like the side effect free
nature of XSLT.
> Maybe JXTG lacks some functionallity needed for important use cases or
> maybe it is still another instance of the hammer anti pattern ;)
The simple fact is JXTG is not appropriate for every conceivable use
case. So please don't bang on it too much. ;-)
>
> /Daniel
>
>
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
Re: xml languages
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>
>>>> Another possibility is to let set asign the value to the first
>>>> variable binding with the same name that it finds when the stack is
>>>> searched,
>>>
>>> -1. Don't think this is a possibility; as noted above, templates
>>> should be side effect free.
>>
>> Glad that you agree :) Eric and Leszek are not convinced at all and
>> want real assignment.
>
> Not 100% true. When introducing the assignment I have always thought
> about JXTG internal variables. I did not realize it could be also used
> to modify the model passed to the view. So how about the solution that
> the execution context has 2 levels on the start:
<snip/>
I think I was not clear enough; I'm against allowing jx:set to change value of
any internal to JXTG variable too. This will force you to do more complicated
stuff (which is usually done using procedural approach) somewhere outside of
JXTG, and in JXTG you use jx:set similarly to XSLT's xsl:variable, to hold
immutable computed value within current execution scope.
Vadim
Re: xml languages
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
>>> Another possibility is to let set asign the value to the first
>>> variable binding with the same name that it finds when the stack is
>>> searched,
>>
>>
>> -1. Don't think this is a possibility; as noted above, templates
>> should be side effect free.
>
>
> Glad that you agree :) Eric and Leszek are not convinced at all and want
> real assignment.
Not 100% true. When introducing the assignment I have always thought
about JXTG internal variables. I did not realize it could be also used
to modify the model passed to the view. So how about the solution that
the execution context has 2 levels on the start:
* root context contains the whole model passed from controller. This
context does not allow neither for variable declaration nor assignment.
* main JXTG context which is a direct child of root context - this one
is empty on the start. This one and all children allow for both
declaration and assignment.
This way all jxtg assignments stay local to the view.
> I would also prefer complete freeness of side effects, but that would
> require us to write an own expression language as both Jexl and JXPath
> allows for calling put methods etc.
This would be nice for the usecase where the user itself can edit a
template via a web application (i.e. jroller). Exposing current jxtg in
that manner would be a great security risk.
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: xml languages
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Vadim Gritsenko wrote:
> Daniel Fagerstrom wrote:
>
>>
>> Ok, that explains the behaviour, the question is what we should do
>> about the, admitingly, weird behaviour.
>
>
> How it is weird - it's same as in xslt.
Not exactly, while xsl:variable is like a final declaration in Java,
jx:set is an asignment and can be used for e.g. counting things in a
forEach. The "weird" part is that you can't define a global variable and
use it as a counter in a sequence of loops as it will be redifined in
the current context if it does not exist there. See Eric Burghard's
example earlier in this thread.
>> One possibilty would be to decide that we want JXTG to be more like a
>> functional language.
>
> +1
>
>> In that case we should deprecate jx:set and introduce a jx:let instead
>> that just gives a local name for an expression and that gives an
>> exception if you try to set the "variable" to a new value.
>
> Not sure this is necessary.
>
>> I think I would prefer this behaviour as I would prefer having a
>> template language without side effects.
>
> +100
>
>> Another possibility is to let set asign the value to the first
>> variable binding with the same name that it finds when the stack is
>> searched,
>
> -1. Don't think this is a possibility; as noted above, templates should
> be side effect free.
Glad that you agree :) Eric and Leszek are not convinced at all and want
real assignment.
I would also prefer complete freeness of side effects, but that would
require us to write an own expression language as both Jexl and JXPath
allows for calling put methods etc.
There is the same problem with extension functions in XSLT, but of some
reason people seem much more interested in using side effects in JXTG
than in XSLT. Maybe JXTG lacks some functionallity needed for important
use cases or maybe it is still another instance of the hammer anti
pattern ;)
/Daniel
Re: xml languages
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Daniel Fagerstrom wrote:
>
> Ok, that explains the behaviour, the question is what we should do about
> the, admitingly, weird behaviour.
How it is weird - it's same as in xslt.
> One possibilty would be to decide that we want JXTG to be more like a
> functional language.
+1
> In that case we should deprecate jx:set and
> introduce a jx:let instead that just gives a local name for an
> expression and that gives an exception if you try to set the "variable"
> to a new value.
Not sure this is necessary.
> I think I would prefer this behaviour as I would prefer
> having a template language without side effects.
+100
> Another possibility is to let set asign the value to the first variable
> binding with the same name that it finds when the stack is searched,
-1. Don't think this is a possibility; as noted above, templates should be side
effect free.
Vadim
Re: xml languages
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
BURGHARD Éric wrote:
>>I'm working on refactoring JXTG so that it will be easier to support and
>>develop. I'm aware about that you have access the request object etc
>
> Great ! Don't know if i can help (time), but if you have a road map or
> something like that, i would be happy to contribute.
I will write a roadmap. All contributions are welcome, a simple but
important contribution is to start using the refactored JXTG instead of
the original and report or even better send patches for the bugs.
>>differently depending on if you are using flow or not and also that the
>>eval tag is less well designed. What more weird behaviours are you
>>thinking of?
>
> Variable nature and scope (kind of non-mutable that you can overwrite ?),
> but someone could tell me this a feature :-). Perhaps i've miss something,
> but look what i need to do to retrieve a value incremented inside a forEach
> loop:
>
> <jx:set var="globalvars" value="${java.util.HashMap(5)}"/>
> <jx:set var="dummy" value="${globalvars.put('a_count', 0)}"/>
> ...
> <jx:set var="a_count" value="${globalvars.a_count}"/>
> <jx:forEach begin="1" end="3" varStatus="i">
> ...
> <jx:if test="#{$node/@path != ''}">
> ...
> <jx:set var="a_count" value="${a_count+1}"/>
> <jx:set var="dummy" value="${globalvars.put('a_count', a_count)}"/>
> </jx:if>
> </jx:forEach>
>
> <jx:out>this is my count: ${globalvars.a_count}</jx:out>
>
> It would be easiest (and efficient) to do
> <jx:set var="a_count" value="0"/>
> <jx:forEach begin="1" end="3" varStatus="i">
> ...
> <jx:if test="#{$node/@path != ''}">
> ...
> <jx:set var="a_count" value="${a_count+1}"/>
> </jx:forEach>
>
> <jx:out>this is my count: ${a_count}</jx:out>
>
> the fact that "set" make always a "new define" is quite annoying at first
> glance (functional programming ?).
The expression context is implemented as a stack of maps and the put
instruction on the context is a put on the top map. ForEach is
implemented in such way that the loop is performed in a local map that
is pushed on stack before the loop and poped afterwards. The set
instruction will do a put on the top map and will disapear afterwards
because of that.
Ok, that explains the behaviour, the question is what we should do about
the, admitingly, weird behaviour.
One possibilty would be to decide that we want JXTG to be more like a
functional language. In that case we should deprecate jx:set and
introduce a jx:let instead that just gives a local name for an
expression and that gives an exception if you try to set the "variable"
to a new value. I think I would prefer this behaviour as I would prefer
having a template language without side effects.
Another possibility is to let set asign the value to the first variable
binding with the same name that it finds when the stack is searched,
instead of creating a new binding at the top of the stack if the name
doesn't exist on the top of the stack. If we go for this we need two
constructions one that declare and possibly gives an intial value to a
variable in the current context and one that binds the uppermost
occurance of the name, a jx:declare and a jx:set e.g.
Also we would need to change the API and behaviour of ExpressionContext
so that we both have a declare and a set method. This should probably be
done anyway.
WDYT?
/Daniel
Re: xml languages
Posted by BURGHARD Éric <er...@systheo.com>.
> I'm working on refactoring JXTG so that it will be easier to support and
> develop. I'm aware about that you have access the request object etc
Great ! Don't know if i can help (time), but if you have a road map or
something like that, i would be happy to contribute.
> differently depending on if you are using flow or not and also that the
> eval tag is less well designed. What more weird behaviours are you
> thinking of?
Variable nature and scope (kind of non-mutable that you can overwrite ?),
but someone could tell me this a feature :-). Perhaps i've miss something,
but look what i need to do to retrieve a value incremented inside a forEach
loop:
<jx:set var="globalvars" value="${java.util.HashMap(5)}"/>
<jx:set var="dummy" value="${globalvars.put('a_count', 0)}"/>
...
<jx:set var="a_count" value="${globalvars.a_count}"/>
<jx:forEach begin="1" end="3" varStatus="i">
...
<jx:if test="#{$node/@path != ''}">
...
<jx:set var="a_count" value="${a_count+1}"/>
<jx:set var="dummy" value="${globalvars.put('a_count', a_count)}"/>
</jx:if>
</jx:forEach>
<jx:out>this is my count: ${globalvars.a_count}</jx:out>
It would be easiest (and efficient) to do
<jx:set var="a_count" value="0"/>
<jx:forEach begin="1" end="3" varStatus="i">
...
<jx:if test="#{$node/@path != ''}">
...
<jx:set var="a_count" value="${a_count+1}"/>
</jx:forEach>
<jx:out>this is my count: ${a_count}</jx:out>
the fact that "set" make always a "new define" is quite annoying at first
glance (functional programming ?).
Regards.
Re: xml languages
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 21 janv. 05, à 11:11, Daniel Fagerstrom a écrit :
> ...Having an attribute template alternative to XSLT for XML to XML
> transformations is another thing...
ok, got it thanks!
-Bertrand
Re: xml languages
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Bertrand Delacretaz wrote:
> Le 21 janv. 05, à 10:14, Daniel Fagerstrom a écrit :
>
>> ...If you or someone else would like to make XSLT easier to use as
>> template language, I would be happy to help with design discussions.
>> But I have lost my interest in pushing for or implementing such a
>> thing...
>
>
> Note that such a thing is available *now*, see
> http://wiki.apache.org/cocoon/HtmlToXsltExperiments
> and
> http://blog.bitflux.ch/archive/further-improvements-on-xsl-tal.html
> which I find better
I'm aware of that. But what I refered to with "such a thing", was
something different: using XQuery/XSLT as a template language (a
generator) where you have access to FOM, business objects etc as an XML
view that you can access directly through XQuery/XSLT as either input
document, through document() or through input params. There was a very
long thread about that two years ago that I cited in a previous mail.
With current implementations of XSLT I'm not particulary convinced about
that its a good idea to trying to use them booth for XML to XML
transformations and pulling data from Java beans (which is one of the
main reasons for having template generators).
Having an attribute template alternative to XSLT for XML to XML
transformations is another thing.
/Daniel
> I've talked to Christian Stocker from bitflux about copying his stuff
> in Cocoon, and he said he's ok with the idea of us and them keeping
> parallel versions of his TAL-to-XSLT transform (as he stole some of
> our ideas it's only fair ;-). The simplicity of the thing doesn't
> warrant the effort of maintaining a common version, stealing ideas
> back and forth (with due credit of course) is easier.
>
> I've been meaning to add his stuff as a sample to the new template
> block for a while, with some docs about how to use it, but as usual
> time flies...
>
> -Bertrand
>
>
Re: xml languages
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 21 janv. 05, à 10:14, Daniel Fagerstrom a écrit :
> ...If you or someone else would like to make XSLT easier to use as
> template language, I would be happy to help with design discussions.
> But I have lost my interest in pushing for or implementing such a
> thing...
Note that such a thing is available *now*, see
http://wiki.apache.org/cocoon/HtmlToXsltExperiments
and
http://blog.bitflux.ch/archive/further-improvements-on-xsl-tal.html
which I find better
I've talked to Christian Stocker from bitflux about copying his stuff
in Cocoon, and he said he's ok with the idea of us and them keeping
parallel versions of his TAL-to-XSLT transform (as he stole some of our
ideas it's only fair ;-). The simplicity of the thing doesn't warrant
the effort of maintaining a common version, stealing ideas back and
forth (with due credit of course) is easier.
I've been meaning to add his stuff as a sample to the new template
block for a while, with some docs about how to use it, but as usual
time flies...
-Bertrand
Re: xml languages
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
BURGHARD Éric wrote:
>>This has also been discussed in detail:
>>http://marc.theaimsgroup.com/?t=104930795600004&r=4&w=2
>>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104998241710064&w=2
>>http://marc.theaimsgroup.com/?t=105016536400004&r=1&w=2
>>http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=105178436429214&w=2
>>
>>
>
>thanks a lot for all theses informations, and forgive me for not doing such
>an extensive search myself :-)
>
There have been 1000-2000 posts a month for the last 5 years at dev list
so it is not that easy to find all relevant discussions ;)
>>Might be, and I argued for both the XSLT and Yelly solution before, but
>>I have changed my mind as it wasn't that easy in practice.
>>
>>
>
>yeah, that's right. The best solutions seems to be the less achievable. I
>don't want to throw oil on fire if this is such a touchy subject.
>
Its not a touchy subject, no subjects, as long as they are within the
topic of the list are supposed to be touchy, (except for adding things
to the sitemap maybe ;) ). Just wanted to point out that we have
discussed it before. If you want to take up the dsicussion again, that's
fine with me. If you or someone else would like to make XSLT easier to
use as template language, I would be happy to help with design
discussions. But I have lost my interest in pushing for or implementing
such a thing.
The XSLT development the last few years have IMHO, been disapointing
from an open source POV. Saxon is cool, but Michael Kay have decided to
only add schema awarness and some other interesting things to the
commersial variant of Saxon. Xalan seem to be more about bug fixing the
current version than about developing XSLT 2 or other new ideas. I
haven't seen any design discussions at xalan-dev for years.
> I'm quite
>happy with jxtemplate (apart 3 or 4 weird behaviors)
>
I'm working on refactoring JXTG so that it will be easier to support and
develop. I'm aware about that you have access the request object etc
differently depending on if you are using flow or not and also that the
eval tag is less well designed. What more weird behaviours are you
thinking of?
> and i'm quite
>realistic about our job on xml too (learn another dialect every week and
>waiting for the one :-)...
>
Yeah, that sucks. One of the reasons for focusing on JXTG and not
something new is that we didn't want to tell the existing users of JXTG
that it was time to learn a new template language again.
/Daniel
Re: xml languages
Posted by BURGHARD Éric <er...@systheo.com>.
> This has also been discussed in detail:
> http://marc.theaimsgroup.com/?t=104930795600004&r=4&w=2
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104998241710064&w=2
> http://marc.theaimsgroup.com/?t=105016536400004&r=1&w=2
> http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=105178436429214&w=2
>
thanks a lot for all theses informations, and forgive me for not doing such
an extensive search myself :-)
> Might be, and I argued for both the XSLT and Yelly solution before, but
> I have changed my mind as it wasn't that easy in practice.
>
yeah, that's right. The best solutions seems to be the less achievable. I
don't want to throw oil on fire if this is such a touchy subject. I'm quite
happy with jxtemplate (apart 3 or 4 weird behaviors) and i'm quite
realistic about our job on xml too (learn another dialect every week and
waiting for the one :-)...
Anyway i don't know enough about the different architectures, to speak
smartly, but just didn't see why this was possible with jxtg and not with
jelly/xslt. Not so easy is a kind of "try it yourself", but i trust you,
and i appreciate that you answer my question ;-)
> /Daniel
thanks.
regards
Re: xml languages
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
BURGHARD Éric wrote:
>hi everybody,
>
>I'm a little disapointed by all theses xml languages we can found around
>which nearly all do the same things.
>
>1) Last time i wanted to construct a project with maven and i found jelly.
>it had a rich tag library, handle jexl expressions, and can handle xpath
>through tag's libraries. But, as maven users, you all know that.
>
>So my question (naïve), is why not using jelly (jelly generator) instead of
>redo the work with jxtemplate. I wonder why using ant mutant anteater too,
>because IMHO testing with ant+jelly+junit+http(client) is much more
>powerfull (multipart post, upload file, ...). And we could certainly define
>a new tag library (macros) and run the anteater scripts "as is" with jelly.
>
Different alternatives to JXTemplateGenerator has been discussed in a
number of (long) threads, some of them cited at
http://wiki.apache.org/cocoon/Templates. And the conclusion was that we
think that JXTG is good enough for our needs, but that it needs
refactoring to be easier to support, refine and possibly extend for the
community. I'm currently working on refactoring it (and would be happy
if others joined).
As you can see in some of the threads people are quite negative (or even
aggresive towards) taglibs. So being able to easily write own taglibs is
not part of our requirement list.
When it comes to using a JellyGenerator both Carsten and I have done
some work on that and wasn't particulary happy about it. OTH Peter Royal
had more success
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110225841413218&w=2.
But the community just didn't show any entusiasm at all about basing our
work on Jelly (or other externally developed frameworks).
A large part of the implementation of a template language is about
integration with the underlying framework (Cocoon), so IMO it makes
sense to have an own template language even if I thought it was an
instance of "not invented here" first.
>2) I play last time with saxon8 and xpath/xslt2.0. I found that it looks
>much more like a programming language than ever (well it's still xml). I
>like the simplified stylesheet syntax, which allow you to mix the document
>and the stylesheet into one document (like jx).
>
>So is there any plan to add an xslt2.0 generator. Think about a generator
>which add some context variables (like $cocoon), or give access to
>protocols (like cocoon:/) inside in your template.
>
This has also been discussed in detail:
http://marc.theaimsgroup.com/?t=104930795600004&r=4&w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104998241710064&w=2
http://marc.theaimsgroup.com/?t=105016536400004&r=1&w=2
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=105178436429214&w=2
Problems with using XSLT2 or XQuery is that at least two years ago the
licence of Saxon (MPL 1.0) was not considered to be compatible with the
Apache License so Cocoon can (could?) not be bundled with Saxon. And
Xalan does not implement XSLT2 or XQuery yet.
Also an important requirement is to be able to access bean structures
from the template language. This can be done from Xalan or Saxon (as
discussed in the above threads), but it is not that easy to control
efficency. Then Chris Oliver implemented JXTG so there was not much
reason to continue these issues.
>these 2 candidates have a bigger audience than jxtemplate.
>
Might be, and I argued for both the XSLT and Yelly solution before, but
I have changed my mind as it wasn't that easy in practice.
/Daniel
Re: xml languages
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Peter Hunsberger wrote:
> On Thu, 20 Jan 2005 20:58:51 +0100, Daniel Fagerstrom
> <da...@nada.kth.se> wrote:
>
> <snip>existing generator/transformer approaches</snip>
>
>>>What many people seem to want is a template language other than XSLT.
>>>Personally, I agree that that seems to be re-inventing the wheel, but
>>>open source communities seem to like constant mutant evolution...
>>
>>The problem with using XSLT as template language is that it is hard to
>>get pull access to Java beans. You can of course serialize your Java
>>object to SAX with e.g. Castor or Betwixt in a generator or a source.
>>But that soon becomes expensive if you just want to access a little data
>>from a large Java object.
>
>
> If you're working with a legacy system I can see this. If you're
> starting from scratch I think this shouldn't be a real issue: don't
> write large Java objects or make sure that they are used in their
> entirety.
The small or large Java objects often are connected to each other in a
graph or a tree e.g. So you have to write some directives for Castor etc
about what part of the graph you want to serialize.
> For us, there's a pretty close mapping between the database layer and
> what we want to see as raw XML. Our approach, is basically
>
> EJB -> proxy -> datasource -> generator -> XSLT
>
> where the datasource is looked up using a factory pattern against the
> database for a generic generator. The datasource handles the
> conversion of the data classes handed off from the EJB layer to XML
> but all of our beans are designed from the get go to map to the front
> end requirements.
It might be an excelent solution in some cases but for the moment I'm
more interested in contributing to making simple things simple in Cocoon
than in making complicated things possible (which they allready are).
So I think it is nice to be able to do "the simplest thing that could
possibly work" like:
JavaBean -> JXTG -> HTMLSerializer
whithout having to think about what enterprise patterns I would like to
use today, teach my colleague about them and about how to use Castor,
how to write beans that fits the frontend, how to use XSLT etc, and
trying to understand what it does a couple of months later.
Of course in many cases you need more complex approaches but quite
often, YAGNI.
/Daniel
Re: xml languages
Posted by Peter Hunsberger <pe...@gmail.com>.
On Thu, 20 Jan 2005 20:58:51 +0100, Daniel Fagerstrom
<da...@nada.kth.se> wrote:
<snip>existing generator/transformer approaches</snip>
> >
> > What many people seem to want is a template language other than XSLT.
> > Personally, I agree that that seems to be re-inventing the wheel, but
> > open source communities seem to like constant mutant evolution...
>
> The problem with using XSLT as template language is that it is hard to
> get pull access to Java beans. You can of course serialize your Java
> object to SAX with e.g. Castor or Betwixt in a generator or a source.
> But that soon becomes expensive if you just want to access a little data
> from a large Java object.
If you're working with a legacy system I can see this. If you're
starting from scratch I think this shouldn't be a real issue: don't
write large Java objects or make sure that they are used in their
entirety.
For us, there's a pretty close mapping between the database layer and
what we want to see as raw XML. Our approach, is basically
EJB -> proxy -> datasource -> generator -> XSLT
where the datasource is looked up using a factory pattern against the
database for a generic generator. The datasource handles the
conversion of the data classes handed off from the EJB layer to XML
but all of our beans are designed from the get go to map to the front
end requirements.
<snip>lazy DOM adapter approach</snip>
--
Peter Hunsberger
Re: xml languages
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Peter Hunsberger wrote:
> On Thu, 20 Jan 2005 15:07:25 +0100, BURGHARD Éric
> <er...@systheo.com> wrote:
<snip/>
>>So is there any plan to add an xslt2.0 generator. Think about a generator
>>which add some context variables (like $cocoon), or give access to
>>protocols (like cocoon:/) inside in your template.
There is such a generator (TraxGenerator) in scratchpad. Don't know how
well it works. Nothing special is needed for XSLT 2.0, it uses AFAIK the
same interface, javax.xml.transform, as XSLT 1.0.
> You can already do more-or-less exactly that: just aggregate some
> generators (like the request generator) and feed them to Saxon 8
> (though we use Saxon 7) as a transformer step to apply whatever
> transforms you want. If you want to use XSLT 2 then use it.
>
> What many people seem to want is a template language other than XSLT.
> Personally, I agree that that seems to be re-inventing the wheel, but
> open source communities seem to like constant mutant evolution...
The problem with using XSLT as template language is that it is hard to
get pull access to Java beans. You can of course serialize your Java
object to SAX with e.g. Castor or Betwixt in a generator or a source.
But that soon becomes expensive if you just want to access a little data
from a large Java object.
What you need is some kind of lazy DOM adapter for the Java beans, that
only access the parts of the bean that correspond to the parts of the
DOM that is accessed by the XSLT processor. There is such a DOM adapter
(o.a.c.components.jxdom.DocumentAdapter) in scratchpad. Don't know about
the quality of that either. Chris Oliver wrote the TraxGenerator and the
DocumentAdapter during the "In search of the perfect template language"
thread that I cited in my previous mail. But he lost his belief in that
approach and wrote JXTG instead.
I also spent consideral time in refactoring Betwixt to be able to become
a lazy DOMAdapter. But didn't have time to finish it.
My current view is that it would be nice to be able to use XQuery or
XSLT 2.0 on Java bean structure, but that it require considerable work
to make it work well with current implementations. And I don't feel that
itch anymore.
/Daniel
Re: xml languages
Posted by Peter Hunsberger <pe...@gmail.com>.
On Thu, 20 Jan 2005 15:07:25 +0100, BURGHARD Éric
<er...@systheo.com> wrote:
> hi everybody,
>
> I'm a little disapointed by all theses xml languages we can found around
> which nearly all do the same things.
>
> 1) Last time i wanted to construct a project with maven and i found jelly.
> it had a rich tag library, handle jexl expressions, and can handle xpath
> through tag's libraries. But, as maven users, you all know that.
>
> So my question (naïve), is why not using jelly (jelly generator) instead of
> redo the work with jxtemplate. I wonder why using ant mutant anteater too,
> because IMHO testing with ant+jelly+junit+http(client) is much more
> powerfull (multipart post, upload file, ...). And we could certainly define
> a new tag library (macros) and run the anteater scripts "as is" with jelly.
>
> 2) I play last time with saxon8 and xpath/xslt2.0. I found that it looks
> much more like a programming language than ever (well it's still xml). I
> like the simplified stylesheet syntax, which allow you to mix the document
> and the stylesheet into one document (like jx).
>
> So is there any plan to add an xslt2.0 generator. Think about a generator
> which add some context variables (like $cocoon), or give access to
> protocols (like cocoon:/) inside in your template.
You can already do more-or-less exactly that: just aggregate some
generators (like the request generator) and feed them to Saxon 8
(though we use Saxon 7) as a transformer step to apply whatever
transforms you want. If you want to use XSLT 2 then use it.
What many people seem to want is a template language other than XSLT.
Personally, I agree that that seems to be re-inventing the wheel, but
open source communities seem to like constant mutant evolution...
--
Peter Hunsberger