FYI, Terence Parr (the StringTemplate ANTLR author) just sent this to
me. Thought the list would find this interesting
Tony
Original Message
From: Terence Parr [EMAIL PROTECTED]
Subject: Re: [RT] StringTemplate: The answer to our templating needs?
Date: Thu, 4 Nov 2004 11
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while Jexl is
mostly useless in that case but is straightforward when you deal
with JavaBeans. I also agree that understanding the difference
between ${continuation.id} and
Daniel Fagerstrom dijo:
I agree with Sylvain. I mainly use expression languages for accessing
DOM trees, and we write a lot of XSLT at my company, so for us JXPath
(or other XPath based expression languages) is the natural choice. For
people who mainly work in Java, and use Cocoon as a view
Leszek Gawron dijo:
I think that all templating languages that are not xml based will also
introduce character encoding problems.
Yep.
I say: let's stick to JXTG just add some power with the ability to write
more sophisticated macros/taglibs.
hint tm=CZThe next line is not a formal
Tony Collen wrote:
Do we need a new, (standardized?) or possibly even *gasp* better
templating system for Cocoon? This is where I encourage people to dive
in and give their own [RT]s and thoughts on the issue.
First, thank you for the pointer. Interesting stuff.
But first, we should agree on
On Fri, 29 Oct 2004, Reinhard Poetz wrote:
Tony Collen wrote:
Do we need a new, (standardized?) or possibly even *gasp* better
templating system for Cocoon? This is where I encourage people to dive
in and give their own [RT]s and thoughts on the issue.
First, thank you for the pointer.
Reinhard Poetz wrote:
Tony Collen wrote:
Do we need a new, (standardized?) or possibly even *gasp* better
templating system for Cocoon? This is where I encourage people to
dive in and give their own [RT]s and thoughts on the issue.
First, thank you for the pointer. Interesting stuff.
But
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while
Jexl is mostly useless in that case but is straightforward
when you deal with JavaBeans. I also agree that understanding
the difference between ${continuation.id} and
#{$continuation/id} is less than
Le 29 oct. 04, à 10:17, Carsten Ziegeler a écrit :
...Hmm, one of the things I really don't like with JXTG is that you
have to different expression languages. You never know which to
use and some things work only with one specific language.
And for me this comes near to FS :)
Yes - but
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while
Jexl is mostly useless in that case but is straightforward
when you deal with JavaBeans. I also agree that understanding
the difference between ${continuation.id} and
Bertrand Delacretaz wrote:
I don't think JXTG is broken now, it works well but the code
is hard to understand and having all classes in a single huge
source code file does not help.
Yupp, that is one of the problems with JXTG. It would be great if
a new solution would be pluggable to add
Sylvain Wallez wrote:
That's exactly what I suggest above: we choose a standard
default language, but open the possibility to plug in new
ones. XPath is a must-have, Jexl and IM have very valid use
cases which IMO justify them to be provided by Cocoon. Other
languages are just a
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Sent: Friday, October 29, 2004 10:47 AM
To: [EMAIL PROTECTED]
Subject: RE: [RT] StringTemplate: The answer to our templating needs?
Bertrand Delacretaz wrote:
I don't think JXTG is broken now, it works well
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
That's exactly what I suggest above: we choose a standard
default language, but open the possibility to plug in new
ones. XPath is a must-have, Jexl and IM have very valid use
cases which IMO justify them to be provided by Cocoon. Other
languages
Bart Molenkamp wrote:
Bertrand Delacretaz wrote:
I don't think JXTG is broken now, it works well but the
code is hard
to understand and having all classes in a single huge source code
file does not help.
Yupp, that is one of the problems with JXTG. It would be great if a
Tony Collen wrote:
--
Well, I was too quick on the key presses, so here goes again. Sorry for
the spam :)
--
Brought to you by the maniac that brings you ANTLR!
A while ago I was investigating different templating languages, and I
came across one
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while
Jexl is mostly useless in that case but is straightforward
when you deal with JavaBeans. I also agree that understanding
the difference between ${continuation.id} and
#{$continuation/id}
Carsten Ziegeler wrote:
Bart Molenkamp wrote:
Bertrand Delacretaz wrote:
I don't think JXTG is broken now, it works well but the
code is hard
to understand and having all classes in a single huge source code
file does not help.
Yupp, that is one of the problems with JXTG. It would be great if
Leszek Gawron wrote:
And if there are language constructs that are not possible to
implement with JXPath and JavaBeans? And I am sure there are
(I had some problems myself but shoot me in the head: I do
not remember the exact cases). Should we be saying to users:
it does not work with
Bart Molenkamp wrote:
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Sent: Friday, October 29, 2004 10:47 AM
To: [EMAIL PROTECTED]
Subject: RE: [RT] StringTemplate: The answer to our templating needs?
Bertrand Delacretaz wrote:
I don't think JXTG is broken now
Reinhard Poetz wrote:
No, you're right - this is a possible danger. But as long
as we only
make it pluggable and be careful that we don't fall into
this trap, I
see no problem with it.
The question is: Do we want to prevent our users from this or
is it their own decision?
Reinhard Poetz wrote:
No, you're right - this is a possible danger. But as long as we only
make it pluggable and be careful that we don't fall into this trap,
I see no problem with it.
The question is: Do we want to prevent our users from this or is it
their own decision?
Applying constraints on
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
It's their own decision. Now in the end you can't prevent users
from doing so - and perhaps, although we think that it's wrong it
might be exactly what they need for their use case. I definitly
have the need to plug my own tags into JXTG ;)
I cannot
On 29.10.2004 13:07, Carsten Ziegeler wrote:
It's their own decision. Now in the end you can't prevent users
from doing so
But that's exactly what the document is about: *enforcing* separation
instead of *encourage*. StringTemplate claims to provide that.
Joerg
Le 29 oct. 04, à 12:59, Reinhard Poetz a écrit :
Bart Molenkamp wrote:
...
No, you're right - this is a possible danger. But as long as we only
make it pluggable and be careful that we don't fall into this trap,
I see no problem with it.
The question is: Do we want to prevent our users from this
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
That's exactly what I suggest above: we choose a standard
default language, but open the possibility to plug in new
ones. XPath is a must-have, Jexl and IM have very valid use
cases which IMO justify them to be provided by Cocoon. Other
Carsten Ziegeler wrote:
Bertrand Delacretaz wrote:
I don't think JXTG is broken now, it works well but the code
is hard to understand and having all classes in a single huge
source code file does not help.
Yupp, that is one of the problems with JXTG. It would be great if
a new solution would be
Carsten Ziegeler wrote:
Leszek Gawron wrote:
And if there are language constructs that are not possible to
implement with JXPath and JavaBeans? And I am sure there are
(I had some problems myself but shoot me in the head: I do
not remember the exact cases). Should we be saying to users:
it
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
That's exactly what I suggest above: we choose a standard default
language, but open the possibility to plug in new ones. XPath is a
must-have, Jexl and IM have very valid use cases which IMO justify
them to be provided by
Le 29 oct. 04, à 15:05, Vadim Gritsenko a écrit :
Sylvain Wallez wrote:
...Technically this should be possible, but how do we write something
like widget.getChild(foo).getAttribute(bar) in XPath?
Tecnically, this will be
getAttribute(getChild($widget, foo), bar)
in JXPath. Not exactly easy to
Vadim Gritsenko wrote:
like a template generator/transformer, input moduls, java code etc.
About Java code, do you mean in Actions, Transformers, etc?
Or, you mean flowscript beans?
No, I meant Action, Transformers etc.
Carsten
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
What can you do with Jexl what you can't do with an XPath based
language? My understanding is that they only differ in their syntax
('.' instead of '/').
Now even if Jexl has more functionality I don't see a reason why
this
Bertrand Delacretaz wrote:
Le 29 oct. 04, à 15:05, Vadim Gritsenko a écrit :
Sylvain Wallez wrote:
...Technically this should be possible, but how do we write something
like widget.getChild(foo).getAttribute(bar) in XPath?
Tecnically, this will be
getAttribute(getChild($widget, foo), bar)
in
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
like a template generator/transformer, input moduls, java code etc.
About Java code, do you mean in Actions, Transformers, etc?
Or, you mean flowscript beans?
No, I meant Action, Transformers etc.
If you already thought about it, how would you pass
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Bertrand Delacretaz wrote:
Le 29 oct. 04, à 15:05, Vadim Gritsenko a écrit :
Sylvain Wallez wrote:
...Technically this should be possible, but how do we write something
like
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
like a template generator/transformer, input moduls, java code etc.
About Java code, do you mean in Actions, Transformers, etc?
Or, you mean flowscript beans?
No, I meant Action, Transformers etc.
If you
Vadim Gritsenko wrote:
Bertrand Delacretaz wrote:
Le 29 oct. 04, à 15:05, Vadim Gritsenko a écrit :
Sylvain Wallez wrote:
...Technically this should be possible, but how do we write
something like widget.getChild(foo).getAttribute(bar) in XPath?
Tecnically, this will be
Le 29 oct. 04, à 15:51, Sylvain Wallez a écrit :
Vadim Gritsenko wrote:
Bertrand Delacretaz wrote:
...
And technically in plain XPath it would be something like
//widget/foo/@bar
IIUC, JXPath has pluggable introspectors, so it above can be reduced
to:
$widget/foo/@bar
Eeek. Do you really
To: [EMAIL PROTECTED]
Subject: Re: Expression languages (was Re: [RT] StringTemplate: The
answer
to our templating needs?)
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
What can you do with Jexl what you can't do with an XPath based
language? My understanding
Bertrand Delacretaz wrote:
Le 29 oct. 04, à 15:51, Sylvain Wallez a écrit :
Vadim Gritsenko wrote:
Bertrand Delacretaz wrote:
...
And technically in plain XPath it would be something like
//widget/foo/@bar
IIUC, JXPath has pluggable introspectors, so it above can be reduced
to:
Bertrand Delacretaz wrote:
Le 29 oct. 04, à 15:51, Sylvain Wallez a écrit :
Vadim Gritsenko wrote:
Bertrand Delacretaz wrote:
...
And technically in plain XPath it would be something like
//widget/foo/@bar
IIUC, JXPath has pluggable introspectors, so it above can be reduced to:
Le 29 oct. 04, à 17:20, Vadim Gritsenko a écrit :
..But we were talking about getChild(foo)...
got it now - thanks ;-)
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Leszek Gawron said:
JXTG is very good but it lacks a way to extend it with some reusable
pieces of
code (macros).
I have been trying to make some other templating languages be usable with
cocoon but all of them are generating TEXT and in cocoon xml land this is
a
real problem. Here
Giacomo Pati wrote:
On Fri, 29 Oct 2004, Reinhard Poetz wrote:
Tony Collen wrote:
Do we need a new, (standardized?) or possibly even *gasp* better
templating system for Cocoon? This is where I encourage people to
dive in and give their own [RT]s and thoughts on the issue.
First, thank you for
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while
Jexl is mostly useless in that case but is straightforward
when you deal with JavaBeans. I also agree that understanding
the difference between ${continuation.id} and
#{$continuation/id}
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while Jexl is
mostly useless in that case but is straightforward when you deal with
JavaBeans. I also agree that understanding the difference between
${continuation.id}
Carsten Ziegeler wrote:
Bertrand Delacretaz wrote:
I don't think JXTG is broken now, it works well but the code
is hard to understand and having all classes in a single huge
source code file does not help.
Yupp, that is one of the problems with JXTG. It would be great if
a new solution would be
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
I created a long time ago the TemplateObjectModelHelper which is
in the scratchpad area. The idea of this class is to provide one
single object model that can be used in various components,
like a template generator/transformer, input moduls, java code
Brought to you by the maniac that brings you ANTLR!
A while ago I was investigating different templating languages, and I
came across one called StringTemplate [1]
[1] http://www.stringtemplate.org/doc/doc.tml
Of particular interest is the author's paper, _EnforcingModel-View
Separation in
--
Well, I was too quick on the key presses, so here goes again. Sorry for
the spam :)
--
Brought to you by the maniac that brings you ANTLR!
A while ago I was investigating different templating languages, and I
came across one called StringTemplate
50 matches
Mail list logo
