cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allan Erskine <a.ersk...@cs.ucl.ac.uk>
Subject Re: App Design Philosophy Rant
Date Tue, 13 Feb 2001 02:56:05 GMT
I wholeheartedly agree...I had a mini-rant myself about a month ago but me
being quite new to C2 it was long on rant, short on substance and quite
rightly greeted with a deafening silence.

Didn't stop me thinking about it, although I've been busy on a web-app
(doing it your no 2 way).  Would like to try refactoring to a possible third
way...

I don't have anything to flesh this out, but my main thoughts were to have
logicsheet level abstractions for classes of entities commonly dealt with in
web-apps, such as tables, forms etc, and a means of composing them.

Each class abstraction would have a corresponding SAX XMLfilter
implementation.  Logicsheet level class objects could then be composed at
tag level, with the implementations being composed at XMLfilter level.

These abstractions would be natural candidates as emitters and receivers of
(filtered) actions.

Still short on substance I know, but what about the general idea?

----- Original Message -----
From: "Uli Mayring" <ulim@denic.de>
To: <cocoon-users@xml.apache.org>
Sent: Tuesday, February 13, 2001 12:22 AM
Subject: App Design Philosophy Rant


> 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
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
> For additional commands, e-mail: <cocoon-users-help@xml.apache.org>
>


Mime
View raw message