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:query>select * from blah</esql:query> sounds easy enough, but in real life it's more something like
<esql:connection>
<esql:pool>gump</esql:pool>
<esql:execute-query>
<esql:query>
SELECT name,description FROM projects ORDER BY name
</esql:query>
<esql:results>
<esql:row-results>
<li>
<a><xsp:attribute name="href">projects?name=<esql:get-string column="name"/></xsp:attribute><esql: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:pool>gump</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.
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
<li><a href="projects?name=${project.name}">${project.name}</a> - ${project.description}</li>
#end
</ul>
or view.template (attribute style):
<ul x:foreach="project in projects">
<li><a 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.
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!
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.
Taglibs force template designers to do the job of content population or force two different people to work on the same file.
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.
Everything else is making a step backwards.
As said above my only purpose with introducing taglibs is to increase maintainability and the ability to test things. Take a look at the Cocoon code base. Tons of code that hide what it does beyond all this SAX event handling code. If we could refactor away some of that intermingling, we would IMO make a step forward.
You keep mixing concerns.
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 and #2 so attacking #3 now is more harmful than useful.
-- Stefano.
