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: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. 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: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.
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 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.
/Daniel
