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
<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!
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.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 writing code for query composition and execution in an action variant of flowscript I also agree :), I think that its better than doing it in a generator step.
So why are we not allready doing that? Booth allow the use of flowscripts as actions (after having inactivated web continuations) and providing DB functions for flowscripts have been discussed a number of times at the list. And every time a number of committers (you included), have explained (for both of the ideas) that: its not needed, its mix of concern and it is generally bad practice.
If you succeed in convincing the community that (flow)script actions and flowscript support for DB is ok, and should be our "official recomendation" for db reporting stuff, I have no need for SQL-tags anymore. Until that happens they fill a clear need.
<snip/>
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.
Let me tell a story from real life. I and some others have worked hard on enforcing SoC, enterprise design patterns and generally layered designs in all our projects. That have been excelent for ensuring the success for larger project. But a less excelent side effect is that a number of people who was quite productive in small projects using php and the like have become very frustrated over the, in their view, overly abstract way of doing things. And a few of them even hate Cocoon based on that.
My conclusion from this is that its counter productive and destructive to force people to follow your own rigid idea about the "ideal" SoC. Do simple things in simple ways. If the project grows, introduce the needed design and refactor.
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.
We also need recursive application of named templates, othewise you cannot render menu trees, folders and the like.
<snip/>
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.
We went over #1 and #2 a number of times at the list, and the design this far is based on the results of these discussions, and every design issue has been repported at the list and in some cases discussed. Please resarch the archives, if you doubt it.
When you wrote the letter that I'm responding to, you and Miles where the only ones that had expressed any frustration at all. Now everybody are frustrated, it says something interesting about mail list dynamic doesn't it.
Anyway we can take a new itteration with #1 and #2 if you and others feel like that. Please write an RT where you give more details about your view.
/Daniel
