The danger of overseparating concerns (was Re: [Design] JXTG 2.0 (Just my opinion))

[Sylvain Wallez <sy...@apache.org>]

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 }

Re: The danger of overseparating concerns (was Re: [Design] JXTG 2.0 (Just my opinion))

[Glen Ezkovich <gl...@hard-bop.com>]

On Dec 4, 2004, at 12:24 PM, Sylvain Wallez wrote:
>
> 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).

This where we are currently having problems. When a site is more of an 
application then just a publication. Mainly our problems are with 
forms, we would like to use CForms but are finding it difficult to 
integrate with the rest of our architecture (and its a lot of XML). I'm 
sure we will find a way ... eventually. But the point you make is well 
taken and becoming painfully obvious.


Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.hard-bop.com



A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to 
worry about answers."
- Thomas Pynchon Gravity's Rainbow

Re: The danger of overseparating concerns (was Re: [Design] JXTG 2.0(Just my opinion))

[Antonio Gallardo <ag...@agssa.net>]

On Sab, 4 de Diciembre de 2004, 12:24, Sylvain Wallez dijo:
> 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).

More and more I am convinced that the pain is more related to a reporting
(publishing?) tool than to a new language.

Best Regards,

Antonio Gallardo

Re: The danger of overseparating concerns (was Re: [Design] JXTG 2.0 (Just my opinion))

[Bertrand Delacretaz <bd...@apache.org>]

Le 4 déc. 04, à 19:24, Sylvain Wallez a écrit :

<snip interesting experiences/>

> ...Of course, this is related to our organisation where template 
> writers have more a developer background.

Right. And the problem now is that there is no simple way for people to 
move from "designer-friendly" environments to Cocoon-based publishing 
in small steps. They have to do a big jump, where many probably fall on 
their face ;-)

> ...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...

Agreed. OTOH your view is very html-centric IIUC. In situations where 
multi-channel output (web, mobile, print for example) is required, a 
two-step view brings many benefits. But you're right that in such case 
the first step is rarely pure XML, it's often biased towards the most 
common/preferred output format.

-Bertrand