Stefano Mazzocchi wrote: <snip/>
Now there are two approaches:
1) model 1: taglibs 2) model 2: controller + view
3) model 3: taglibs + 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.
We always use the 3:rd model. The first taglibs part contains the same stuff as you put in the controller but it is written by people who are skilled in SQL but they are in most cases not programmers. The view is written in XSLT, it might be designed by a designer in Dreamweaver, but then a developer typically embed it in XSLT so that we can use the same design for many pages.
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.
Come on, with such comparisons you can prove anything. Don't you remember that you based Cocoon on xml-pipelines any more?
/Daniel
