Sylvain Wallez wrote:
Glen Ezkovich wrote:
On Dec 6, 2004, at 9:00 AM, Sylvain Wallez wrote:
Reinhard Poetz wrote:
Yeah, cocoon-dev has gone crazy during the week-end :-)
more than one EL per template is clear FS to me. I'd be in favor of
specifying EL at the TemplateGenerator declaration time,
On Dec 7, 2004, at 4:19 AM, Leszek Gawron wrote:
Well, if you omit polish, this is no problem for me :-)
And if each phrase is prefixes with the language name, making the
mental switch between ELs (or realizing that I must learn polish) is
not a problem.
Where did that polish example came from
Reinhard Poetz wrote:
IIRC we aggreed that we like the current syntax of JXTemplate.
Exception: We deprecate the #{} notation in favour of ${xpath:}.
If nobody said this already (I have 150 or so mails to go ...), more than one EL
per template is clear FS to me. I'd be in favor of specifying
Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit :
Reinhard Poetz wrote:
IIRC we aggreed that we like the current syntax of JXTemplate.
Exception: We deprecate the #{} notation in favour of ${xpath:}.
If nobody said this already (I have 150 or so mails to go ...), more
than one EL per template
On Dec 6, 2004, at 8:14 AM, Bertrand Delacretaz wrote:
Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit :
Reinhard Poetz wrote:
IIRC we aggreed that we like the current syntax of JXTemplate.
Exception: We deprecate the #{} notation in favour of ${xpath:}.
If nobody said this already (I have 150
Le 6 déc. 04, à 15:41, Glen Ezkovich a écrit :
On Dec 6, 2004, at 8:14 AM, Bertrand Delacretaz wrote:
Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit :
Reinhard Poetz wrote:
IIRC we aggreed that we like the current syntax of JXTemplate.
Exception: We deprecate the #{} notation in favour of
Daniel Fagerstrom wrote:
Bertrand Delacretaz wrote:
Le 6 déc. 04, à 15:41, Glen Ezkovich a écrit :
On Dec 6, 2004, at 8:14 AM, Bertrand Delacretaz wrote:
Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit :
Reinhard Poetz wrote:
IIRC we aggreed that we like the current syntax of JXTemplate.
On Dec 6, 2004, at 8:49 AM, Bertrand Delacretaz wrote:
Le 6 déc. 04, à 15:41, Glen Ezkovich a écrit :
On Dec 6, 2004, at 8:14 AM, Bertrand Delacretaz wrote:
Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit :
Reinhard Poetz wrote:
IIRC we aggreed that we like the current syntax of JXTemplate.
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
IIRC we aggreed that we like the current syntax of JXTemplate.
Exception: We deprecate the #{} notation in favour of ${xpath:}.
If nobody said this already (I have 150 or so mails to go ...),
Yeah, cocoon-dev has gone crazy
On Dec 6, 2004, at 9:00 AM, Sylvain Wallez wrote:
Reinhard Poetz wrote:
Yeah, cocoon-dev has gone crazy during the week-end :-)
more than one EL per template is clear FS to me. I'd be in favor of
specifying EL at the TemplateGenerator declaration time, and would
not go more granular than this.
On Monday 06 December 2004 23:00, Sylvain Wallez wrote:
In that case, a single EL is just painful.
Furthermore, specifying the language in the component declaration
doesn't help readability nor reuse of templates between projects.
Is it only me? I like Java a lot, and how come I can't
Bertrand Delacretaz wrote:
Le 6 déc. 04, à 15:57, Daniel Fagerstrom a écrit :
...What about being able to mix Groovy's XML sytax with the the
ordinary one, wouldn't that be nice ;)
(you just forgot to add the sound of Stefano's FS detector exploding in
the background)
ROTFL
I love you guys :-)
Niclas Hedhman wrote:
On Monday 06 December 2004 23:00, Sylvain Wallez wrote:
In that case, a single EL is just painful.
Furthermore, specifying the language in the component declaration
doesn't help readability nor reuse of templates between projects.
Is it only me? I like Java a lot, and
Glen Ezkovich wrote:
On Dec 6, 2004, at 9:00 AM, Sylvain Wallez wrote:
Reinhard Poetz wrote:
Yeah, cocoon-dev has gone crazy during the week-end :-)
more than one EL per template is clear FS to me. I'd be in favor of
specifying EL at the TemplateGenerator declaration time, and would
not go
On Dec 6, 2004, at 3:32 PM, Sylvain Wallez wrote:
Hmmm... why does this happen? It seems that the java could be
injected by by one component and the XML by another.
Not always, e.g. when you have an XML document and objects describing
its metadata which are both managed by a flowscript.
I did
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
...
Furthermore, specifying the language in the component declaration
doesn't help readability nor reuse of templates between projects.
If you don't see any better way out, I'd go as far as allowing to
choose EL in template
On Tue, 2004-12-07 at 00:45 +0100, Jonas Ekstedt wrote:
On Mon, 2004-12-06 at 22:32 +0100, Sylvain Wallez wrote:
Glen Ezkovich wrote:
On Dec 6, 2004, at 9:00 AM, Sylvain Wallez wrote:
Reinhard Poetz wrote:
Yeah, cocoon-dev has gone crazy during the week-end :-)
On Dec 4, 2004, at 8:19 AM, Daniel Fagerstrom wrote:
With that said, a usable taglib-driven system already exists. Jelly.
If you need taglibs, go with that. No need to re-invent something
different in cocoon.
Both I and Carsten have tried to use Jelly in Cocoon but the fit isn't
that good. See
peter royal wrote:
On Dec 4, 2004, at 8:19 AM, Daniel Fagerstrom wrote:
With that said, a usable taglib-driven system already exists. Jelly.
If you need taglibs, go with that. No need to re-invent something
different in cocoon.
Both I and Carsten have tried to use Jelly in Cocoon but the fit
peter royal wrote:
On Dec 2, 2004, at 4:47 PM, Stefano Mazzocchi wrote:
Sure, that's a better syntax, but the fundamental problem remains:
template designers don't know nothing about SQL, nor care, nor know
anything about request parameters, not know anything about dynamic
tags nor know how to
Jonas Ekstedt wrote:
I think the reason for taglibs are that rendering an object is often
more complicated than simply outputting a value. For example, suppose
you want to render a calendar covering the current month. This is a
typical component that would lend itself well as a tag class. The
On Dec 2, 2004, at 4:47 PM, Stefano Mazzocchi wrote:
Sure, that's a better syntax, but the fundamental problem remains:
template designers don't know nothing about SQL, nor care, nor know
anything about request parameters, not know anything about dynamic
tags nor know how to debug something in
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
Stefano Mazzocchi wrote:
Let me re-iterate: there have for a long time been a concesus at the
list among those who have cared enough to discuss it that JXTG is a
well working way of creating views, but that the implementation is
very hard to
Reinhard Poetz wrote:
Stefano Mazzocchi wrote:
One concern is to come up with a unified template language. This implies:
1) understanding the features we want (and we don't want!) from a
template language
2) come up with a syntax
3) implement it
Another and completely separate concern is how
Leszek Gawron wrote:
Jonas Ekstedt wrote:
I think the reason for taglibs are that rendering an object is often
more complicated than simply outputting a value. For example, suppose
you want to render a calendar covering the current month. This is a
typical component that would lend itself well as
Stefano Mazzocchi wrote:
Leszek Gawron wrote:
Jonas Ekstedt wrote:
I think the reason for taglibs are that rendering an object is often
more complicated than simply outputting a value. For example, suppose
you want to render a calendar covering the current month. This is a
typical component that
Stefano Mazzocchi wrote:
snip/
I would be very helpful if we could agree on the above two points with a
vote (and a summary, of course) before moving on.
Stefano,
Unstable blocks doesn't need a vote, and the template one is the result
of unusually extensive mail discussions and also on a general
Stefano Mazzocchi wrote:
Leszek Gawron wrote:
Jonas Ekstedt wrote:
I think the reason for taglibs are that rendering an object is often
more complicated than simply outputting a value. For example, suppose
you want to render a calendar covering the current month. This is a
typical component that
Leszek Gawron wrote:
Stefano Mazzocchi wrote:
${bean.startDate as -MM-DD}
Sure. Still I would like to render my date specially if the date is
before some point in time. My syntax would be:
dateutils:pretty-enhanced-date value=${bean.startDate}
turning-point=2004-01-01/
This way I can
Stefano Mazzocchi wrote:
Let me re-iterate: there have for a long time been a concesus at the
list among those who have cared enough to discuss it that JXTG is a well
working way of creating views, but that the implementation is very hard
to maintain.
There has also been an agreement about
Daniel Fagerstrom wrote:
Stefano Mazzocchi wrote:
Let me re-iterate: there have for a long time been a concesus at the
list among those who have cared enough to discuss it that JXTG is a well
working way of creating views, but that the implementation is very hard
to maintain.
Fair enough. A
Stefano Mazzocchi wrote:
One concern is to come up with a unified template language. This implies:
1) understanding the features we want (and we don't want!) from a
template language
2) come up with a syntax
3) implement it
Another and completely separate concern is how to factor out existing
Stefano Mazzocchi wrote:
The only difference compared to the SQLTransformer would be that I
can combine it with JXTG constructions and insert query params in a
convinient way.
This is exactly the point that makes me say just say no to taglibs
because, as I explained before, no matter what
Miles wrote:
One concern though: Is that results variable a result set or just a
collection of data. If the former, how is the database connection
handled (closing or returning to the pool)? If the latter, how can
large result sets be returned without exhausting memory from a few
On Thu, 2004-12-02 at 16:47 -0500, Stefano Mazzocchi wrote:
snip...
In both cases, they are suboptimal from what I wrote above, where
content population and content presentation are kept completely isolated
and the only contract between the two is:
1) the shape of the objects in the
I was working on an extremely long e-mail about this but Torsten,
Stefano and a repentant Miles covered most of my points. Thanks for the
help and for allowing me to waste my time :-P
However...
It seems that you are trying to do more then just replace the current
functionality JXTG. You want
36 matches
Mail list logo
