cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject The danger of overseparating concerns (was Re: [Design] JXTG 2.0 (Just my opinion))
Date Sat, 04 Dec 2004 18:24:34 GMT
Bertrand Delacretaz wrote:

> Le 3 déc. 04, à 21:40, Glen Ezkovich a écrit :
>
>> ...I'm not sure I agree that templates as being part of the view. I 
>> look at them more as providing XML structure to the data....
>
>
> We need both actually - if you work with the "two-step view" pattern 
> (which is very natural with Cocoon), you need a first set of templates 
> to generate XML out of your data, and a second set to transform the 
> XML into the final presentation format.
>
> Currently we have JXTG for the first step, and mostly XSLT for the 
> second. Having something that could cover both steps and be usable by 
> either programmers working on the first step or designers working on 
> the second would be a Really Good Thing.
>
> -Bertrand
>
> [1] http://www.martinfowler.com/eaaCatalog/twoStepView.html


The two-step-view pattern is good when it doesn't degenerate into 
three-step-view pattern, in which case it becomes highly 
counter-productive. Let me tell you a story from my own experience in my 
company when writing web applications (with lot of forms - publishing is 
a different use case).

We (Anyware) have used a similar approach to TAL years ago, starting 
with Cocoon1 (yes, _years_ ago!). The XSP was doing/calling the 
controller (remember, we could redirect in XSP at that time) and 
producing an XML representation of the data. Next was a XSL 
transformation producing the HTML. That XSL was the result of the 
"compilation" of a DW-compatible HTML page with either some additional 
tags or some attributes like in TAL. We had a DW plugin to edit the 
additional tags (see [1] for some rough explanation of it).

We had a good separation of concerns, DW-friendlyness. That seemed good 
as long as our applications weren't complex. It has to be noted though 
that the produced XSL was a simplfied stylesheet [2], i.e. with no 
pattern-driven rules.

But there was a problem: each XSL, even if generated from annotated 
HTML, contained a lot of graphic stuff, and the graphical layout of the 
application was duplicated in all these HTML pages. Adding some data to 
a page required some web designer skills to edit the HTML template, and 
modifying the overall look of the application required to modify each 
and every page. Painful.

Enter Cocoon 2.0, with its sitemaps and actions. We refactored our 
framework so that the controller was an action, and the XSP was 
therefore only producing data. Now our two-step view had degenerated 
into a three-step view, as the controller was preparing some data 
(objects) for the view, and the first step of the view was merly just 
converting that data to XML. Adding some data to a page required to 
modify 3 files: the action, the XSP and the XSL that formats the XML 
data. Painful again.


With Cocoon 2.1 came flowscript and CForms, and we started using a 
totally different scheme that I find highly productive. At the beginning 
of a project, a prototype GUI is built to ensure that all requirements 
have been taken into account and that we agree on the overall usability 
(this happened previously also). Then, the work can happen in parallel:
- a web designer builds a set of static pages containing all graphical 
structures that are needed for the application,
- the application developpers write the logic and page templates (JXTG) 
containing only _structural_ HTML or other page description language.

The web designer's work is then XSL-ified to a full-blown 
template-driven stylesheet, reacting either to elements (e.g. 
<fieldset>) or class attributes, and is no more a simplified stylesheet 
like we had in our previous approach. The XSL is now really for styling 
and not for templating. Furthemore, we only have one XSL for all forms 
(or one per screen type) instead of one per form (even if generated).

This approach is very productive as the webdesigner and application 
writers work in parallel, and there is abolutely no overlap between 
their respective work. Furthermore, the web design work is highly 
reduced. Of course, this is related to our organisation where template 
writers have more a developer background.


The conclusion of this is that we must be careful of not overseparating 
concerns, as it may actually require more work without real 
architectural benefit.

Note however, that the approach you suggest where the generator produces 
only XML data is valid in publishing-oriented applications where there's 
no controller, as the generator has to perform the data acquisition 
(until we have lightweight controllers that don't require 2 separate 
sitemap executions as flowscript does).

Sylvain

[1] http://marc.theaimsgroup.com/?t=99244278700003&r=1&w=2
[2] http://www.w3.org/TR/xslt#result-element-stylesheet

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message