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
<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!
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="projects"><a 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
