Sylvain Wallez wrote:
You miss an important point here: many Cocoon users are not able to write Java code, and even less a Tag implementation. The purpose of taglibs and template languages is to provide pre-packaged higher-level constructs that hide the underlying complexity.
I'm sorry but I can't take this argument any longer.
Programming is not just learning a syntax, but it's the mapping of a mental model. Mental model that people that write templates simple *DO NOT* have, nor care to have.
Take a look at ESQL for an extreme example in this area :-)
In a perfect world, templates wouldn't need conditionals and iterations, they would come streight out of photoshop, pixel-perfect and flexible at the same time.
Too bad that doesn't apply.
So there is somebody that does the skeleton layout, somebody that does the photoshop prettyfication, and somebody that populates the data the pages need and somebody that mounts the pieces together.
Sometimes, depending on their skills and time availability, a person does more than one of the above tasks. But it's expremely rare (and, by consequence, expensive!) that a single person is able to do all 4 and excel at it.
We are subscribed here because we understand the above perfectly and that's why we believe in framework-enforced SoC.
Now, let's apply that reasoning to the current discussion and let's make the following, very simple, stateless yet dynamic page:
a page that shows the names and ages of the current employees as a table and has the ability to order them by name or by age. The database model is "name, birth-date".
Now, let's take the above situation and write the taglibs that are general enough and simple enough for the people doing the HTML layout to understand.
Now let's analyze what the above would mean in terms of SoC:
1) the "order type" has to be passed to the page, either as a request parameter or as a URL type. In the first case, the sitemap doesn't have to be touched, in the second it does, but pages need to be duplicates, so the template designers will prefer the first.
2) the database model does not contain the age, so that needs to be calculated from the database results
3) the ordering is done either at the database level, or at the page level. in either case, there must be a conditional between the different type of orderings
4) the results need to be iterated, since their number is not known.
Now there are two approaches:
1) model 1: taglibs 2) model 2: controller + view
Model 1 removes all the "underlying machinery" but leaves the "glueing" to the one that does the template design, or forces two people to work on the same file (which is bad).
Model 2 removes both the underlying machinery and the gluing (request -> order, birth-date -> age) and leaves the template designer with iteration.
So, result: Model 2 is a clear winner in terms of SoC analysis, no matter what interfaces the taglibs exhibit, no matter what syntax the templates or the controller have.
Why? because Model 1 removes the machinery but leaves the programmatic glueing (which template designers' mindset don't contemplate).
Model 2 does not.
Result: taglibs are to be considered harmful, no matter what syntax.
-- Stefano.
