cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [Design] JXTG 2.0 (Just say no!)
Date Thu, 02 Dec 2004 18:27:09 GMT
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.


Mime
View raw message