Re: [Design] JXTG 2.0 (Just say yes!)
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 EL at the
TemplateGenerator declaration time, and would not go more granular than this.
Given the above, no need for prefixes (which look ugly to me), and you can
always use same syntax.
Vadim
Re: [Design] JXTG 2.0 (Just say yes!)
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 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...
+1, it might be good to have pluggable languages but run-time switching
is definitely FS - and confusing as well.
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (Just say yes!)
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 or so mails to go ...), 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...
+1, it might be good to have pluggable languages but run-time
switching is definitely FS - and confusing as well.
Thank you. Think this approach is applicable to the tag vs. attribute
debate?
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: [Design] JXTG 2.0 (Just say yes!)
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
${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 EL at the TemplateGenerator declaration time, and would
not go more granular than this...
+1, it might be good to have pluggable languages but run-time
switching is definitely FS - and confusing as well.
Thank you. Think this approach is applicable to the tag vs. attribute
debate?
Sure. Having mixed languages or mixed tag/attributes templating
mechanisms in the same template sounds equally confusing.
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (Just say yes!)
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.
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 EL at the TemplateGenerator declaration time, and
would not go more granular than this...
+1, it might be good to have pluggable languages but run-time
switching is definitely FS - and confusing as well.
Thank you. Think this approach is applicable to the tag vs.
attribute debate?
Sure. Having mixed languages or mixed tag/attributes templating
mechanisms in the same template sounds equally confusing.
What about being able to mix Groovy's XML sytax with the the ordinary
one, wouldn't that be nice ;)
Ring! Ring! Ring! (Stefano's FS alarm bells)
:-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Design] JXTG 2.0 (Just say yes!)
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.
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 EL at the TemplateGenerator declaration time, and would
not go more granular than this...
+1, it might be good to have pluggable languages but run-time
switching is definitely FS - and confusing as well.
Thank you. Think this approach is applicable to the tag vs. attribute
debate?
Sure. Having mixed languages or mixed tag/attributes templating
mechanisms in the same template sounds equally confusing.
LOL. It did seem obvious to me. Should never have phrased it as a
question.
I think this might also work in other ways as well. Considering the
heat of the taglib debate (where, I think a lot of misunderstanding
occurred on both sides), this might be able to get the benefits of
using a taglib like approach to the implementation of template
generators/transformers. Same basic component gets a tag/attribute
library evaluator (excuse the phrase, brain freeze occurred concerning
the proper term ... or maybe I got it right ;-)). Seems that this way
the only difference between a JXTG and a SQLTG would be the way they
were configured in the sitemap and the library they were configured to
use.
The approach could be flexible enough to allow any combination to be
configured, allowing those who think they have such a use case, to
commit virtual suicide. Saner minds can do their best to prevent abuse
by threatening immediate termination upon such egregious configuration
of components. ;-)
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: [Design] JXTG 2.0 (Just say yes!)
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 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.
I don't agree: it happens quite often to have mixed view data combining
java objects and XML. In that case, a single EL is just painful.
It just says a lot about state of the art in the expression language arena but
does not demonstrate a need for more than one! :)
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 itself, using attribute on the root element. I'd not go further, though.
Vadim
Re: [Design] JXTG 2.0 (Just say yes!)
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.
I don't agree: it happens quite often to have mixed view data
combining java objects and XML.
Hmmm... why does this happen? It seems that the java could be injected
by by one component and the XML by another.
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.
Readability of what, the sitemap or the template.
Frankly, while it adds complexity to the sitemap, it only does so for
template generators/transformers. I think understandability will be
more affected by naming choices then the configuration complexity. Only
needing to interpret a single EL in a template undoubtedly improves
readability. Imagine me writing this using french, polish and english
phrases randomly interspersed.
I don't see how this affects reusability.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
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: [Design] JXTG 2.0 (Just say yes!)
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 construct the page parts in Java as well? Is it that people really love to learn 15 different programming languages when one can do more than enough? Tapestry, IMHO, have got a lot of things right. Let the programmers use Java and let the designers use Dreamweaver (or whatever their personal choice is). Having the programmers crank out some tr statements isn't that much of a deal, but blurring the pitcure of who is in charge of the template is. The designer knows shit-all about any programming construct and the programmer knows shit-all about design (pardon my french). Maybe this community is a lot about people who think that they are in the middle and can do both... no offense :o) , most real-world projects are not organized in that manner. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+
Re: [Design] JXTG 2.0 (Just say yes!)
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 :-) -- Stefano.
Re: [Design] JXTG 2.0 (Just say yes!)
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 how come I can't construct the page
parts in Java as well? Is it that people really love to learn 15 different
programming languages when one can do more than enough?
Tapestry, IMHO, have got a lot of things right. Let the programmers use Java
and let the designers use Dreamweaver (or whatever their personal choice is).
Having the programmers crank out some tr statements isn't that much of a
deal, but blurring the pitcure of who is in charge of the template is. The
designer knows shit-all about any programming construct and the programmer
knows shit-all about design (pardon my french).
Well, I for one hate writing tons of Java to build a screen, despite
being a Java developer since JDK 1.1.x. A screen is a declarative thing
to me, and the natural language to build it is some kind of XML.
Furthermore, I want to organize it as I want, without having to ask a
webdesigner to change the location of a button. That's why I love
templates that produce structural layout markup (e.g. html with classes)
that is styled down the pipeline by various transformations and CSS.
Maybe this community is a lot about people who think that they are in the
middle and can do both... no offense :o) , most real-world projects are not
organized in that manner.
Be careful: the concept of real-world project is a highly varying
concept here :-)
Tapestry provides only one way to do things, meaning its users have to
accept this way or switch to another framework. Cocoon is at the other
end by providing so many ways of doing things that there cannot be a
single imposed way. Like it or not, that part of what makes Cocoon so
special and used in so many different contexts. And the kilometer-long
thread on JXTG 2.0 clearly shows this :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Design] JXTG 2.0 (Just say yes!)
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 more granular than this.
I don't agree: it happens quite often to have mixed view data
combining java objects and XML.
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.
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.
Readability of what, the sitemap or the template.
Reusability of the template, since you don't know just by reading the
template source file what EL was used to write it.
Frankly, while it adds complexity to the sitemap, it only does so for
template generators/transformers. I think understandability will be
more affected by naming choices then the configuration complexity.
Only needing to interpret a single EL in a template undoubtedly
improves readability. Imagine me writing this using french, polish and
english phrases randomly interspersed.
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.
I don't see how this affects reusability.
Yes it does, since moving templates around require to be sure that the
component they're processed with is configured for the right expression
language.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Design] JXTG 2.0 (Just say yes!)
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 think about this and a few other similar cases. Because we are
considering template generation and template transformation it would be
possible to use the metadata to construct the template that will be
used by the transformer. I'm not sure I like this, but that is one of
the ideas that has been mentioned. Also I think its possible for one
expression language to be used to work with both Java and XML using
appropriate syntax. It seems that something like ${/abc/def/ghi} and
${myObject.myMethod();} could coexist in a single EL. What would need
to be invalid are expressions like ${/abc/def/myobject.myMethod()}. I'm
not sure I like it. Its not completely aesthetically pleasing but it is
better then document(@href)/*/node(). ;-) (maybe it is possible to use
the current XPath and Jexl implementations and just do some syntax
validation up front)
Readability of what, the sitemap or the template.
Reusability of the template, since you don't know just by reading the
template source file what EL was used to write it.
So you are saying that if you have two expression languages its going
to be easier ;-) As it is, you know that it is either XPath or Jexl.
Well, that is assuming you are using JXTG. If you are not, what EL is
being used? If you can understand it I think you'd have a pretty good
idea what the EL was. This like saying if you pick up an novel in
english you can't tell what language is used. Granted multiple
expression languages can have similar syntaxes and be semantically
different. Wouldn't it be odd (and wonderful) if templates written in
one would produce correct but totally different results in the other.
Talk about reusability. Not that I think this would happen. My point
is, if it makes sense, then you probably know what EL is being used. If
you are wrong and it still works correctly, who cares. :P
Frankly, while it adds complexity to the sitemap, it only does so for
template generators/transformers. I think understandability will be
more affected by naming choices then the configuration complexity.
Only needing to interpret a single EL in a template undoubtedly
improves readability. Imagine me writing this using french, polish
and english phrases randomly interspersed.
Well, if you omit polish, this is no problem for me :-)
Maybe not the best example :-) It's usually not a problem for me either
when I know that multiple languages are used. Syntactically, two or
more ELs could be quite similar and thus hard to always know which you
are reading. I really don't have a problem with the fact that someone
wants to use two or more ELs in the same template. I can see use cases
where having two, three or more ELs available could be a very useful
thing. I also think with the ability to generate a template, these use
cases will become fewer.
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.
No its not. However, one of the things I have learned over the years is
that not everyone is capable of making context switches quickly. I do
believe that if you wish to use multiple ELs, you should be able to...
by configuring your component to do so. I just would like to prevent my
team from doing so unless no acceptable alternative exists.
I don't see how this affects reusability.
Yes it does, since moving templates around require to be sure that the
component they're processed with is configured for the right
expression language.
I agree. But the same is true with any component. This is where
documentation and testing come in.
I think the out of the box cocoon should be as simple as possible. When
you are at the point of having your metadata in java objects and your
data in XML I would think that 15 minutes to configure a generator or
transformer would be a worth while investment of your time.
I don't see how things are damaged that much by having to configure
your components in the sitemap. I know XPer's believe that the
documentation is the code and Cocooners tend to hate writing doc
comments. For both the constraints and power of configurable components
I don't think its to much to ask of your template designers to list the
ELs used in the template in some comments.
Now after all this, I'm going to take the advice of the subject line
and just say YES. Refactor JXTG. Then 90% of the battle will be won by
us all. I think all of this is tangential to the real task at hand.
Clean elegant code makes me happy.
Didn't all this start with an effort to stabilize CForms? Its been so
long I forget.
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
Re: [Design] JXTG 2.0 (Just say yes!)
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 itself, using attribute on the root element. I'd not go further, though. Mmmh... like XSP does... BTW, isn't it you that added Python and JavaScript support to XSP? ;-) But... But... But see, I had never suggested to use several languages in the same page, at once! :-P Vadim
Re: [Design] JXTG 2.0 (Just say yes!)
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 :-)
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.
I don't agree: it happens quite often to have mixed view data
combining java objects and XML.
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.
Fully agree. Restricting expressions to only one type would be quite bad
I think. In addition to xpath and jelly it would also be cool with
formatting expressions (ie ${format:jelly-expression#type}). As an
example of all three types (xpath, jelly and format) consider a site
with some articles and a calendar on it:
body
pYour last login: ${format:user.lastLogin#short}/p
h3This months calendar/h3
calendar:month currentDate=${jelly:today}/
h3Articles/h3
dom:out select=${xpath:/domVariable/articles/article}
/body
Cheers Jonas
Oops! jelly - jexl
// jonas
Re: [Design] JXTG 2.0 (Just say yes!)
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 our posts in http://marc.theaimsgroup.com/?t=10993268021r=1w=2. Ah, I missed that thread :) I have Jelly working pretty well in Cocoon. You can modify the JellyContext to take a Source object and use that to create the template. And the templates are thread-safe, its just that each template invocation will require a new JellyContext object. There are a few edges where usages of URL could be replaced with Source, but not that many. The implementation is just a few adapter classes and works great! I'm happy to share with anyone interested in pursuing this further. -pete
Re: [Design] JXTG 2.0 (Just say yes!)
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 isn't that good. See our posts in http://marc.theaimsgroup.com/?t=10993268021r=1w=2. Ah, I missed that thread :) I have Jelly working pretty well in Cocoon. You can modify the JellyContext to take a Source object and use that to create the template. And the templates are thread-safe, its just that each template invocation will require a new JellyContext object. There are a few edges where usages of URL could be replaced with Source, but not that many. The implementation is just a few adapter classes and works great! I'm happy to share with anyone interested in pursuing this further. -pete Thanks for your offer, but I've joined the NIH camp, so its to late for me ;) Furthermore, Jelly doesn't seem like such an active project anymore. The script compilation is just a part of the project, factoring out and solidifying contracts for expression handling and other stuff is at least as important. To me it just didn't seem worthwhile enough to fight with Jelly's interfaces and implementation to get it to do what I wanted. And it also takes time and engagement to convince another community about adopting your suggestions. I mean its hard enough for me in the Cocoon community ;) And also you know what we Cocooners think about basing our core stuff on others code ;) /Daniel
Re: [Design] JXTG 2.0 (Just say yes!)
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 debug something in case somebody screws up with the order of those tags! taglibs are *very* useful for applications. a programmer (that may or may not have knowledge of how to use tags) can construct a form using a tag library. the constructed document can then be rendered to multiple mediums.. rich browser UI, static PDF, tables to XLS, simple HTML for handhelds. the template designer just creates one master template for each output medium. a programmer actually writes the implementation of that template. 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 our posts in http://marc.theaimsgroup.com/?t=10993268021r=1w=2. /Daniel
Re: [Design] JXTG 2.0 (Just say yes!)
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
template writer would simply do:
calendar:month current-date=${myDate}/
The tag might output something like this:
month value=2
week value=12
day value=5 name=Monday/
day value=6 name=Tuesday current=true/
day value=7 name=Wednesday/
...
/week
...
/month
Later transformations would transform it into a table or whatever. This
type of calendar would be very hard to do for a template author without
the help of a tag library.
I have completely no time these days so I was just waiting for the
single post to say: Cannot agree more here :)
The current discussion about taglibs have focused very much on esql and
whether SQL belongs in templates or not. I agree that SQL in templates
are a bad idea, but that is really beside the point in regards to the
virtues of taglibs.
Exactly. Everyone concentrated on ESQL as a taglib while this is the
WORST example there is. ESQL does a lot of persistence logic and can
have enormous side effects. Taglibs should have no side effects at all.
Taglibs (in my view) are primarily about converting
objects to SAX. Here are a few ideas for taglibs that only deals with
presentation of objects (as opposed to esql which also populates).
* Bean renderers
jx:set var=ignored
value=${Packages.com.something.DateUtil.emitPrettyDate( bean.startDate,
cocoon.consumer/ - is this one better than the taglib? Or should I
implement a stylesheet that would parse my 100kB xml file just to look
for dateutils:prettydate value=2003-01-01/ ?
* DOM renderers
* ResultSet renderers (ie renders a query made in flow)
* Menus
* Page navigation
* Tabs (similar to tabs in CForm)
* CForm tags
* cinclude
* Calendars (showing week, month etc.)
* wiki renderers
currently I do something like to parse wiki syntax:
function radeoxToSAX( str, consumer ) {
var radeoxStr = radeoxEngine.render( str, radeoxContext );
var buffer = new java.lang.StringBuffer(root );
buffer.append( radeoxStr )
buffer.append( /root );
var is = new Packages.org.xml.sax.InputSource( new java.io.StringReader(
buffer.toString() ) );
var parser = null;
var includeConsumer = new org.apache.cocoon.xml.IncludeXMLConsumer( consumer, consumer );
includeConsumer.setIgnoreRootElement( true );
try {
parser = cocoon.getComponent( Packages.org.apache.excalibur.xml.sax.SAXParser.ROLE );
parser.parse( is, includeConsumer );
} finally {
if ( parser != null ) cocoon.releaseComponent( parser );
}
}
jx:macro name=radeox-string
jx:parameter name=value/
jx:set var=ignored value=${cocoon.session.radeox( value,
cocoon.consumer )}/
/jx:macro
snip/
radeox-string value=${project.description}/
This clearly is a hack and should be implemented as taglib.
* ValueList renderers
a taglib that supports displaying a narrowed list of values,
searchable, paginable and so on
The items above are in my view better examples of the benefits of
taglibs. They're all about how to render an object. The object is
populated in flow but how to render it is implemented in the tag
classes.
Maybe we should stop using taglib word. What we're trying to do may
simply be harmed by the emotions that this phrase carries.
Sure all taglibs/convertors/renderers could be implemented as
stylesheets or custom transformers. But creating a pipeline with 15
transformations (which by the way mainly would do identity
transformations and expand only specific tags) is neither performant nor
elegant. In case of custom transformers it's also never easy.
--
Leszek Gawron [EMAIL PROTECTED]
Project ManagerMobileBox 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: [Design] JXTG 2.0 (Just say yes!)
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 case somebody screws up with the order of those tags! taglibs are *very* useful for applications. a programmer (that may or may not have knowledge of how to use tags) can construct a form using a tag library. the constructed document can then be rendered to multiple mediums.. rich browser UI, static PDF, tables to XLS, simple HTML for handhelds. the template designer just creates one master template for each output medium. a programmer actually writes the implementation of that template. 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. For document-centric production, sure, what's your fighting against is totally valid. But taglibs have their place too (even if the idea may be used in inappropriate places) -pete
Re: [Design] JXTG 2.0 (Just say yes!)
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 maintain.
Fair enough. A template language has nothing to do with taglibs, per se.
There has also been an agreement about that ESQL is the only reason
(besides back compability) to care about XSP, you said so youself a
week ago or so.
After using it for a little while, I changed my mind. :-)
Ok
For those of us who use CForms it is very convenient to be able to
use the template tags together with JXTG constructs.
I believe the best template system does not use tags at all. It either
uses content (as in velocity) or it uses attributes (as in tapestry).
In our previous discussion at the list our conclusion was that JXTG is
ok and that although there might be slightly better approaches or
ideas in one way or another, the general feeling was that it would be
better to evolve from JXTG than to do something completely different. We
must protect our users investments in Cocoon technology. Of course we
should do new and revolutionary stuff when we find a much better way of
doing things. But that something is slightly better is not a good enough
reason, IMO.
Having said that, I'm happy to keep the template framework open enough
to make it possible to plug in an attribute driven approach or parsers
for content driven approaches. It should be quite easy to do that AFAIK.
Now, these are no itches that I have, but if you or some one else come
upp with a design proposal for such a template language, I can take part
in adapting the framework for it.
snip/
In the general case I would rather write just the query with some
surrounding tags like in the SQLTransformer, get a simple
standardized XML serialization of the row set and then transform it
to HTML in XSLT.
That works only for trivial monolythic cases. For any serious
reporting application (for example, where order is parameter
dependable) that doesn't work.
I assumed the context of the having both SQL and JX tags in the
generator step, then you can do serious reporting. I even happen to know
that, as I and my coleagues have done serious repporting in numerous
applications for a number of years in that way.
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 syntax, putting query
parameters in a SQL string is not something that should be in a template!
Ok, I start to realize that you assume that I suggest that everything
should be done in the template step. No I don't, I do what you refer to
as the controler concern, i.e. put together and execute the SQL query
based on request params in the template. All view related stuff is done
in the next step, typically XSLT.
snip/
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 case somebody screws up with
the order of those tags!
let me rewrite the above:
controller.script:
var query = SELECT name,description +
FROM projects +
WHERE project= + request.id +
ORDER BY name ;
var results = cocoon.datasources.gump.execute(query);
request.context.set(projects,results);
view.template (content style):
ul
#foreach project in projects
lia href=projects?name=${project.name}${project.name}/a -
${project.description}/li
#end
/ul
or view.template (attribute style):
ul x:foreach=project in projects
lia href=projects?name=${project.name}${project.name}/a -
${project.description}/li
/ul
note how SoC also allows you to use a different technology (example,
O/R or straight OODBMS or even RDF triple stores!) to populate the
beans without the template designers know anything about this!
What I want is something like this:
- request comes
- sitemap gets it
- matcher matches
- controller is executed and populates beans in the request context
- pipeline is invoqued with access to the request context
- response goes
Now, this can happen right now in flow and JXtemplate. If we don't
need state management, this is just like having a better action
model with XSP-like code recompilation.
Concerning SoC I agree completely, It is a good idea to separate the
query composition and execution from the result set rendering, I have
always done it that way and have never recomended anyone to mix them.
Concerning writing code for query composition and execution in an action
variant of flowscript I also agree :), I think that its better than
doing
Re: [Design] JXTG 2.0 (Just say yes!)
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 to factor out existing bits so that #3 is easier. You are attacking #3 before attacking #1 and #2 and that's why everybody here is feeling frustration: there is no consensus on #1 I don't think so. There were tons of mails and IMHO we agreed on a list of features (maybe a final summary is missing) 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.
Re: [Design] JXTG 2.0 (Just say yes!)
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 a tag class. The
template writer would simply do:
calendar:month current-date=${myDate}/
The tag might output something like this:
month value=2
week value=12
day value=5 name=Monday/
day value=6 name=Tuesday current=true/
day value=7 name=Wednesday/
...
/week
...
/month
Later transformations would transform it into a table or whatever. This
type of calendar would be very hard to do for a template author without
the help of a tag library.
I have completely no time these days so I was just waiting for the
single post to say: Cannot agree more here :)
I cannot disagree more.
${myDate as month}
will do the above without mentioning tags (and will be much more
Dreamweaver-friendly).
The current discussion about taglibs have focused very much on esql and
whether SQL belongs in templates or not. I agree that SQL in templates
are a bad idea, but that is really beside the point in regards to the
virtues of taglibs.
Exactly. Everyone concentrated on ESQL as a taglib while this is the
WORST example there is. ESQL does a lot of persistence logic and can
have enormous side effects. Taglibs should have no side effects at all.
excuse me? what side effect does a SELECT have?
Taglibs (in my view) are primarily about converting
objects to SAX.
If this is the case, then taglib is a *VERY BAD* name. I agree that
some objects might be sax-ified differently, depending on user needs,
but the name taglibs makes the syntactic and the semantic concern
overlap and annoys people (like me) that ended up hating dynamic XML
tags after promoting them for so long.
Here are a few ideas for taglibs that only deals with
presentation of objects (as opposed to esql which also populates).
* Bean renderers
jx:set var=ignored
value=${Packages.com.something.DateUtil.emitPrettyDate( bean.startDate,
cocoon.consumer/ - is this one better than the taglib? Or should I
implement a stylesheet that would parse my 100kB xml file just to look
for dateutils:prettydate value=2003-01-01/ ?
I completely agree that the transformation stage is overkill, that's not
my point.
I think that better than both you can do
${bean.startDate as -MM-DD}
* DOM renderers
excuse me?
* ResultSet renderers (ie renders a query made in flow)
are you kidding? regular iteration is all you need.
* Menus * Page navigation * Tabs (similar to tabs in CForm)
what?
* CForm tags
the above ${var as flavor} will do
* cinclude
no way
* Calendars (showing week, month etc.)
see above
* wiki renderers
currently I do something like to parse wiki syntax:
function radeoxToSAX( str, consumer ) {
var radeoxStr = radeoxEngine.render( str, radeoxContext );
var buffer = new java.lang.StringBuffer(root );
buffer.append( radeoxStr )
buffer.append( /root );
var is = new Packages.org.xml.sax.InputSource( new
java.io.StringReader( buffer.toString() ) );
var parser = null;
var includeConsumer = new
org.apache.cocoon.xml.IncludeXMLConsumer( consumer, consumer );
includeConsumer.setIgnoreRootElement( true );
try { parser = cocoon.getComponent(
Packages.org.apache.excalibur.xml.sax.SAXParser.ROLE );
parser.parse( is, includeConsumer );} finally {
if ( parser != null ) cocoon.releaseComponent( parser );
}
}
jx:macro name=radeox-string
jx:parameter name=value/
jx:set var=ignored value=${cocoon.session.radeox( value,
cocoon.consumer )}/
/jx:macro
OH COME ON! you can do a generator and cinclude a subpipeline for that.
snip/
radeox-string value=${project.description}/
This clearly is a hack and should be implemented as taglib.
You will have to step on my dead body before that's the case.
* ValueList renderers
a taglib that supports displaying a narrowed list of values,
searchable, paginable and so on
The items above are in my view better examples of the benefits of
taglibs. They're all about how to render an object. The object is
populated in flow but how to render it is implemented in the tag
classes.
Maybe we should stop using taglib word. What we're trying to do may
simply be harmed by the emotions that this phrase carries.
No matter what you call it, if you want to have dynamic XML tags, you
will hurt yourself, your wiki example is the kind of things that gives
me the creeps.
--
Stefano.
Re: [Design] JXTG 2.0 (Just say yes!)
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 would lend itself well as a tag class. The
template writer would simply do:
calendar:month current-date=${myDate}/
The tag might output something like this:
month value=2
week value=12
day value=5 name=Monday/
day value=6 name=Tuesday current=true/
day value=7 name=Wednesday/
...
/week
...
/month
Later transformations would transform it into a table or whatever. This
type of calendar would be very hard to do for a template author without
the help of a tag library.
I have completely no time these days so I was just waiting for the
single post to say: Cannot agree more here :)
I cannot disagree more.
${myDate as month}
will do the above without mentioning tags (and will be much more
Dreamweaver-friendly).
Hehe, this is exactly what I outlined in my What do we need taglibs
for? post. The fight is merely about tags vs brace-expansion syntax,
but not about the underlying feature.
snip/
* wiki renderers
currently I do something like to parse wiki syntax:
function radeoxToSAX( str, consumer ) {
var radeoxStr = radeoxEngine.render( str, radeoxContext );
var buffer = new java.lang.StringBuffer(root );
buffer.append( radeoxStr )
buffer.append( /root );
var is = new Packages.org.xml.sax.InputSource( new
java.io.StringReader( buffer.toString() ) );
var parser = null;
var includeConsumer = new
org.apache.cocoon.xml.IncludeXMLConsumer( consumer, consumer );
includeConsumer.setIgnoreRootElement( true );
try { parser = cocoon.getComponent(
Packages.org.apache.excalibur.xml.sax.SAXParser.ROLE );
parser.parse( is, includeConsumer );} finally {
if ( parser != null ) cocoon.releaseComponent( parser );
}
}
jx:macro name=radeox-string
jx:parameter name=value/
jx:set var=ignored value=${cocoon.session.radeox( value,
cocoon.consumer )}/
/jx:macro
OH COME ON! you can do a generator and cinclude a subpipeline for that.
Or ${wikistring as radeox} :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Design] JXTG 2.0 (Just say yes!)
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 agrement about the direction. Everything is in the mail-archives and I and others have written numerous summaries with vast references to the relevant writings. If you care to check the archives you can see that I and others had all reasons to believe that we did something that was agreed about and wanted by the community. Obviously we don't have an agreement anymore and I'm not going to start any vote about anything until we have found a solution that we can agree about again. Neither will I continue any design or implementation activities in the template area until we can find a constructive way out of this. What I have proposed should be rather clear from my writings and it is quite distant from what I'm accused to propose in your and others reactions. Anyway, I'll wait for your and other critics constructive stated alternatives. An emmotinally over heated crusade against things that neither I or anyone else has proposed will not lead us anywhere. I'll urge you and others that have constructive ideas about what we should do in the templating area to post your ideas. And please focus on what you want rather then what you hate. I'll be happy to continue my involvement in finding, designing and implementing a good template solution that we as a community feel happy about after that. /Daniel
Re: [Design] JXTG 2.0 (Just say yes!)
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 would lend itself well as a tag class. The
template writer would simply do:
calendar:month current-date=${myDate}/
The tag might output something like this:
month value=2
week value=12
day value=5 name=Monday/
day value=6 name=Tuesday current=true/
day value=7 name=Wednesday/
...
/week
...
/month
Later transformations would transform it into a table or whatever. This
type of calendar would be very hard to do for a template author without
the help of a tag library.
I have completely no time these days so I was just waiting for the
single post to say: Cannot agree more here :)
I cannot disagree more.
${myDate as month}
will do the above without mentioning tags (and will be much more
Dreamweaver-friendly).
Sure - but - isn't this only a change at syntax level?. You are
describing a convertor here - something that has been discussed a few
threads before and what Jonas implemented as
#{myDate#full}.
The current discussion about taglibs have focused very much on esql and
whether SQL belongs in templates or not. I agree that SQL in templates
are a bad idea, but that is really beside the point in regards to the
virtues of taglibs.
Exactly. Everyone concentrated on ESQL as a taglib while this is the
WORST example there is. ESQL does a lot of persistence logic and can
have enormous side effects. Taglibs should have no side effects at all.
excuse me? what side effect does a SELECT have?
these:
esql:queryinsert into task values ( something, something ); select
@@identity/esqu:query
still a select from template point of view.
Taglibs (in my view) are primarily about converting
objects to SAX.
If this is the case, then taglib is a *VERY BAD* name. I agree that
This mainly is the case. At least for me.
some objects might be sax-ified differently, depending on user needs,
but the name taglibs makes the syntactic and the semantic concern
overlap and annoys people (like me) that ended up hating dynamic XML
tags after promoting them for so long.
Here are a few ideas for taglibs that only deals with
presentation of objects (as opposed to esql which also populates).
* Bean renderers
jx:set var=ignored
value=${Packages.com.something.DateUtil.emitPrettyDate(
bean.startDate, cocoon.consumer/ - is this one better than the
taglib? Or should I implement a stylesheet that would parse my 100kB
xml file just to look for dateutils:prettydate value=2003-01-01/ ?
I completely agree that the transformation stage is overkill, that's not
my point.
I think that better than both you can do
${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 achieve same formatting across the whole project.
* DOM renderers
excuse me?
not going to defent examples that I did not give. Jonas? :)
* ResultSet renderers (ie renders a query made in flow)
are you kidding? regular iteration is all you need.
agree here
* Menus * Page navigation * Tabs (similar to tabs in CForm)
what?
Jooonas? :))
* wiki renderers
currently I do something like to parse wiki syntax:
function radeoxToSAX( str, consumer ) {
var radeoxStr = radeoxEngine.render( str, radeoxContext );
var buffer = new java.lang.StringBuffer(root );
buffer.append( radeoxStr )
buffer.append( /root );
var is = new Packages.org.xml.sax.InputSource( new
java.io.StringReader( buffer.toString() ) );
var parser = null;
var includeConsumer = new
org.apache.cocoon.xml.IncludeXMLConsumer( consumer, consumer );
includeConsumer.setIgnoreRootElement( true );
try { parser = cocoon.getComponent(
Packages.org.apache.excalibur.xml.sax.SAXParser.ROLE );
parser.parse( is, includeConsumer );} finally {
if ( parser != null ) cocoon.releaseComponent( parser );
}
}
jx:macro name=radeox-string
jx:parameter name=value/
jx:set var=ignored value=${cocoon.session.radeox( value,
cocoon.consumer )}/
/jx:macro
OH COME ON! you can do a generator and cinclude a subpipeline for that.
OH COME ON! :) Transformation to pretty print a date is an overkill.
CInclude for string pretty printing is not?
Moreover imagine you have a simple table:
| project name | project description |
there are 100 rows out of which every description is wikified. that
means 1 generator for the template and 1 for each description. Total 101
generators invoked. Neat.
snip/
radeox-string value=${project.description}/
This clearly is a hack and should be implemented as taglib.
You will have to
Re: [Design] JXTG 2.0 (Just say yes!)
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 achieve same formatting across the whole project.
In the replying-to-hard-topic-stress(tm) I forgot about the question:
How would you pass additional parameters? Or maybe you are considering
it harmful?
--
Leszek Gawron [EMAIL PROTECTED]
Project ManagerMobileBox 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: [Design] JXTG 2.0 (Just say yes!)
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 that ESQL is the only reason
(besides back compability) to care about XSP, you said so youself a week
ago or so.
For those of us who use CForms it is very convenient to be able to use
the template tags together with JXTG constructs.
So we need a template generator with three sets of tags jx:, esql:
and ft: thats it.
We also discused how to use a separate conversion layer to remove the
need for formating constructs from the template layer.
--- o0o ---
Given these general requirements that have been discussed again and
again at the list and also some more technical, performance driven
requirments, I steped forward and proposed a possible way of
implementing it. This design is based on a rather far going SoC in the
interest of keeping it maintainable. We have also identified a number of
templateing components that are needed in other places in Cocoon. E.g.
expression language and object model and therefore are worth
implementing as separate components. I also proposed implementing the
three sets of tags discussed above as taglibs instead of making their
interpretation being part of a huge monolitic SAX event handler as in
JXTG. Implementing it that way it is must easier to write test code for
the tags and generally easier to understand what is going on.
--- o0o ---
Given this background, I was quite suprised when Miles Elam whent
ballistic about that I mentioned the word taglib and draw conclsions
about my intensions that are far and in several cases oposite from what
I feel and have written anything about.
Anyway, if you have better suggestions about how to solve the above
requirements I'm all ears.
--- o0o ---
Now over to commenting what you have written.
So, my other side thinks that having a scripted controller invoquing
different templated views is a better solution.
In this case, do we need taglibs at all? no we don't. esql:queryselect
* from blah/esql:query sounds easy enough, but in real life it's more
something like
esql:connection
esql:poolgump/esql:pool
esql:execute-query
esql:query
SELECT name,description FROM projects ORDER BY name
/esql:query
esql:results
esql:row-results
li
axsp:attribute
name=hrefprojects?name=esql:get-string
column=name//xsp:attributeesql:get-string column=name//a -
esql:get-string column=description/
/li
/esql:row-results
/esql:results
/esql:execute-query
/esql:connection
and *THIS IS THE SIMPLES QUERY I CAN THINK OF*!!!
In the general case I would rather write just the query with some
surrounding tags like in the SQLTransformer, get a simple standardized
XML serialization of the row set and then transform it to HTML in XSLT.
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.
If I would like to do everything in one step as you suggest above it
might look more like:
esql:connection
esql:poolgump/esql:pool
esql:execute-query
esql:query
SELECT name,description FROM projects WHERE
projectleader=${cocoon.request-param.id}ORDER BY name
/esql:query
esql:results
esql:row-results
li
a href=projects?name=${$row.name}/${$row.name}/a -
${$row.description}
/li
/esql:row-results
/esql:results
/esql:execute-query
/esql:connection
As we are using the same kind of expression template mechanisms as in
JXTG. We could probably make the syntax more efficient and take away
some of the tag layers if we feel like that.
What I want is something like this:
- request comes
- sitemap gets it
- matcher matches
- controller is executed and populates beans in the request context
- pipeline is invoqued with access to the request context
- response goes
Now, this can happen right now in flow and JXtemplate. If we don't need
state management, this is just like having a better action model with
XSP-like code recompilation.
Sure, I agree with all that. Only question is: where do I put my SQL
queries in the above scenario?
But the whole point of this discussion is: do we need taglibs?
I'm sorry, but I agree with Miles, we don't: all we need is a
velocity/garbage-like template system and recompilable java controllers.
If you by this mean that you don't see any need in writing special
purpose taglibs as a typical part of normal webapp development, I
couldn't agree more.
Everything else is making a step backwards.
As said above my only purpose
Re: [Design] JXTG 2.0 (Just say yes!)
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 template language has nothing to do with taglibs, per se.
There has also been an agreement about that ESQL is the only reason
(besides back compability) to care about XSP, you said so youself a week
ago or so.
After using it for a little while, I changed my mind. :-)
For those of us who use CForms it is very convenient to be able to use
the template tags together with JXTG constructs.
I believe the best template system does not use tags at all. It either
uses content (as in velocity) or it uses attributes (as in tapestry).
So we need a template generator with three sets of tags jx:, esql:
and ft: thats it.
I disagree, we don't need a set of tags *AT ALL*.
We also discused how to use a separate conversion layer to remove the
need for formating constructs from the template layer.
--- o0o ---
Given these general requirements that have been discussed again and
again at the list and also some more technical, performance driven
requirments, I steped forward and proposed a possible way of
implementing it. This design is based on a rather far going SoC in the
interest of keeping it maintainable. We have also identified a number of
templateing components that are needed in other places in Cocoon. E.g.
expression language and object model and therefore are worth
implementing as separate components. I also proposed implementing the
three sets of tags discussed above as taglibs instead of making their
interpretation being part of a huge monolitic SAX event handler as in
JXTG. Implementing it that way it is must easier to write test code for
the tags and generally easier to understand what is going on.
Very well, you just picked the wrong name: a refactoring of common
services into reusable components has nothing to do with enforcing the
use of tags into a template language.
But more on this later.
--- o0o ---
Given this background, I was quite suprised when Miles Elam whent
ballistic about that I mentioned the word taglib and draw conclsions
about my intensions that are far and in several cases oposite from what
I feel and have written anything about.
keep reading and you might understand why.
Anyway, if you have better suggestions about how to solve the above
requirements I'm all ears.
Here I am.
--- o0o ---
Now over to commenting what you have written.
Bring it on :-)
So, my other side thinks that having a scripted controller invoquing
different templated views is a better solution.
In this case, do we need taglibs at all? no we don't.
esql:queryselect * from blah/esql:query sounds easy enough, but in
real life it's more something like
esql:connection
esql:poolgump/esql:pool
esql:execute-query
esql:query
SELECT name,description FROM projects ORDER BY name
/esql:query
esql:results
esql:row-results
li
axsp:attribute
name=hrefprojects?name=esql:get-string
column=name//xsp:attributeesql:get-string column=name//a -
esql:get-string column=description/
/li
/esql:row-results
/esql:results
/esql:execute-query
/esql:connection
and *THIS IS THE SIMPLES QUERY I CAN THINK OF*!!!
In the general case I would rather write just the query with some
surrounding tags like in the SQLTransformer, get a simple standardized
XML serialization of the row set and then transform it to HTML in XSLT.
That works only for trivial monolythic cases. For any serious reporting
application (for example, where order is parameter dependable) that
doesn't work.
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 syntax, putting query
parameters in a SQL string is not something that should be in a template!
If I would like to do everything in one step as you suggest above it
might look more like:
esql:connection
esql:poolgump/esql:pool
esql:execute-query
esql:query
SELECT name,description FROM projects WHERE
projectleader=${cocoon.request-param.id}ORDER BY name
/esql:query
esql:results
esql:row-results
li
a href=projects?name=${$row.name}/${$row.name}/a -
${$row.description}
/li
/esql:row-results
/esql:results
/esql:execute-query
/esql:connection
As we are using the same kind of expression template mechanisms as in
JXTG. We could probably make the syntax more efficient and take away
some
Re: [Design] JXTG 2.0 (Just say yes!)
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
bits so that #3 is easier.
You are attacking #3 before attacking #1 and #2 and that's why everybody
here is feeling frustration: there is no consensus on #1
I don't think so. There were tons of mails and IMHO we agreed on a list of
features (maybe a final summary is missing)
and #2 so
IIRC we aggreed that we like the current syntax of JXTemplate. Exception: We
deprecate the #{} notation in favour of ${xpath:}.
attacking #3 now is more harmful than useful.
hmmm, IMO #1 and #2 was done ...
--
Reinhard
Re: [Design] JXTG 2.0 (Just say yes!)
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 syntax, putting query
parameters in a SQL string is not something that should be in a template!
Thank you.
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 case somebody screws up with
the order of those tags!
let me rewrite the above:
controller.script:
var query = SELECT name,description +
FROM projects +
WHERE project= + request.id +
ORDER BY name ;
var results = cocoon.datasources.gump.execute(query);
request.context.set(projects,results);
view.template (content style):
ul
#foreach project in projects
lia href=projects?name=${project.name}${project.name}/a -
${project.description}/li
#end
/ul
or view.template (attribute style):
ul x:foreach=project in projects
lia href=projects?name=${project.name}${project.name}/a -
${project.description}/li
/ul
note how SoC also allows you to use a different technology (example,
O/R or straight OODBMS or even RDF triple stores!) to populate the
beans without the template designers know anything about this!
Thank you! If this isn't a case study of what to do with simple
queries, I don't know what is.
Personally I like:
ul x:test=projects
li x:context=projectsa href=projects?name=${name}${name}/a -
${description}/li
/ul
Where each item in projects becomes the reference scope. ;-) If there
are no projects, no list tags are written. But then, I'm one of those
weird guys who doesn't mind seeing things like ${.} occasionally to
refer to the current iterated item. I also have to admit a love for
test conditionals that don't require the explicit != null grammar.
Hey! We can all dream, right?
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
queries? That's the one case where I see ESQL winning out. All other
cases where you aren't dumping the contents of a table, this seems like
an excellent idea. If a web developer can't handle that much scripting,
what chance do they have with an ESQL taglib?
Sure, I agree with all that. Only question is: where do I put my SQL
queries in the above scenario?
this is the whole stinking point: *never* in the template!
Thank you.
But the whole point of this discussion is: do we need taglibs?
I'm sorry, but I agree with Miles, we don't: all we need is a
velocity/garbage-like template system and recompilable java
controllers.
If you by this mean that you don't see any need in writing special
purpose taglibs as a typical part of normal webapp development, I
couldn't agree more.
No, not only that: I think that the person responsible for doing
writing the logic that drives the flow *and* the content population of
the page is *NOT* the same person that does the design of the template.
Thank you.
- Miles Elam
RE: [Design] JXTG 2.0 (Just say yes!)
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 queries? That's the one case where I see ESQL winning out. Surely the controller script should handle this too? After calling the template it should clean up the model.
Re: [Design] JXTG 2.0 (Just say yes!)
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 context
2) how to perform simple variable espansion, list iteration and
conditioning.
#2 is the only thing that should be exposed to a template language (just
like velocity does), everything else should be dealt with at the view
population level. Which is going to be code, written by coders and
people that deal a lot better with code than with anything else.
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
template writer would simply do:
calendar:month current-date=${myDate}/
The tag might output something like this:
month value=2
week value=12
day value=5 name=Monday/
day value=6 name=Tuesday current=true/
day value=7 name=Wednesday/
...
/week
...
/month
Later transformations would transform it into a table or whatever. This
type of calendar would be very hard to do for a template author without
the help of a tag library.
The current discussion about taglibs have focused very much on esql and
whether SQL belongs in templates or not. I agree that SQL in templates
are a bad idea, but that is really beside the point in regards to the
virtues of taglibs. Taglibs (in my view) are primarily about converting
objects to SAX. Here are a few ideas for taglibs that only deals with
presentation of objects (as opposed to esql which also populates).
* Bean renderers
* DOM renderers
* ResultSet renderers (ie renders a query made in flow)
* Menus
* Page navigation
* Tabs (similar to tabs in CForm)
* CForm tags
* cinclude
* Calendars (showing week, month etc.)
The items above are in my view better examples of the benefits of
taglibs. They're all about how to render an object. The object is
populated in flow but how to render it is implemented in the tag
classes.
Cheers Jonas
Re: [Design] JXTG 2.0 (Just say yes!)
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 to include the possibility processing the kitchen sink. I think this is what's bothering many of us. This will lead to breaking the separation of concerns. While implementing this in a template may seem better then implementing it in an XSP, in the end I suspect it will be just as ugly. The only thing that will change is the syntax. Semantically, it will be just as ugly. There is already too much power in the existing JXTG. On the other hand, I find the idea of a general template generator intriguing. I think you might be on to something, but I think you are missing it. Ok so you want a replacement for JXTG, create a tag library and have the template generator use it. You want the functionality of ESQL without XSP, create a tag library for it. Want to process CSVs, write a tag library for it. Want to process excel spreadsheets, create a tag library. The problem is that generally you declare the libraries in the document in which they are used and can use as many libraries as you want. This is where the evil part of tag libs comes in. It allows you to do anything and everything in one place. No separation of concerns can be enforced. View, controller, model all can be intermingled. Suppose, that instead of allowing all Tag Libraries to be used by the generator, each generator could only use one library. That is JXTG could only process JXTG tags, SQLTG could only process ESQL tags, ExcelTG could only process EXCEL tags, etc. TemplateGenerator is a perfect candidate for an abstract class. Each subclass just needs to have a Tag Library with which to work. This makes it much easier to implement other template generators just implement a new Tag Library and some constructors. Of course nothing prevents someone from adding multiple libraries to their generator should they choose to do so. They can deal with the consequences. This gives you the flexibility in design you want. It gives you the functionality that you want, since it is unlikely that you will want to access java objects and then access a database. It also helps limit the abuse that tag libraries can engender. Just my 0.02 . Now if I could just come up with a way to keep all html tags out of the JX templates. 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
