Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm
Date: Tue, 13 Feb 2001 01:22:16 +0100 (MET)
From: Uli Mayring <ulim@denic.de>
To: cocoon-users@xml.apache.org
Subject: App Design Philosophy Rant
Message-ID: <Pine.GSO.4.10.10102130024340.3249-100000@denics7.denic.de>
"X-Ncc-RegID: de.denic"
MIME-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on notes/Denic(Release 5.0.4 |June 8,
 2000) at 13.02.2001
 01:22:15,
	Serialize by Router on notes/Denic(Release 5.0.4 |June 8, 2000) at 13.02.2001
 01:22:17,
	Serialize complete at 13.02.2001 01:22:17
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

Hi all,

First, two fictitious code samples, which I haven't tested and which might
not work. They are only here to illustrate the discussion that follows.


First Example, which assumes exactly one result row in esql:

String url = "";
<esql:connection>
...
	<esql:row-results>
		result = <esql:get-string column="URL"/>;
	</esql:row-results>
...
</esql:connection>
...
response.sendRedirect(url);


Second example, which assumes ten result rows:

String[] result = new String[10]
<esql:row-results>
	result[<esql:get-row-position/>] = <esql:get-string column="FOO"/>;
</esql:row-results>


Third example:

if (action.equals("insert")) {
	...
		<esql:query>
			insert into TABLE foo values('bar')
		</esql:query>
	...
	}
if (action.equals("update")) {
	...
		<esql:query>
			update TABLE set foo='bar'
		</esql:query>
	...
	}

This stuff looks a bit evil, doesn't it? We are talking about two
different principles of app design here:

1) Like above, put everything in the XML file and use XSLT just for
straightforward and unintelligent rewriting of XML into HTML.

2) Write clean esql queries, then parse the generated XML intelligently in
an XSLT stylesheet and transform (not merely rewrite) to HTML.

I've designed my apps according to 2) up to now. But my stylesheet kept 
getting bigger and bigger all the time - most of the application logic
went into the stylesheet! The esql queries selected each and every piece
of data that I might need and the XSLT stylesheet made the selection based
on the current situation.

This is very stupid. First, it's slow, because XSLT is slower than XSP.
Then I have generic queries, which are "good for every case", and use only
a portion of their results in each possible branch within the XSLT. This
is much overhead. And lastly, most of my application's workflow logic ends
up in the XSLT stylesheet in deeply nested <xsl:choose> blocks - resulting
in the mother of unmaintainable apps.

So I decided to rewrite my latest and greatest app according to 1). Now I
have a halfway decent stylesheet, but the XML pages look like hell. I
still like it better than before, but it's not the type of seperation
between content and logic that Cocoon seems to promise. It's not "XML data
driving the processes", it's more like "hard-coding processes in Java and
using Cocoon to fetch data and wrap it in < and >".

Now, I've used esql on purpose in the examples, because it's the cleanest
and most powerful taglib we have. But, looking at the examples above, it
seems to lack a lot in terms of expressiveness. Now, we could say it's not
esql's job to define app design. Rather, we should write a seperate taglib
providing the kind of expressiveness we need - but what good would that be
if it couldn't cooperate with esql and other taglibs?

For example, let's look at the power and expressiveness that esql's
get-nested-string template provides. I stole this cool template for my own
taglibs and so should every taglib author. Hm.. doesn't make much sense
putting its functionality in a seperate taglib - we don't want our taglibs
to depend on "foreign" taglibs, they should be self-contained. So let's
just all steal the template and thus have redundant code.

I imagine any generic taglib that aims to provide seperation of logic and
content on a higher level will have exactly that problem. For it to
make sense, its functionality should be usable everywhere, i.e. also
within blocks of tags from other taglibs.

How to solve this dilemma? My only idea is to provide a cocoon-specific
"application layer" - currently that layer is Java inside <xsp:logic>
blocks. Perhaps we should write a higher level Java framework for Cocoon
applications and perhaps put that in a central taglib. All other taglibs
would then kind of "inherit" its functionality. Yes, I know this sucks,
because it is extremely proprietary.

Any other ideas? Does Cocoon2 consider this issue?

Ulrich

-- 
Ulrich Mayring
DENIC eG, Softwareentwicklung