Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <002d01c0c8d6$3fb27370$ea4dfea9@spukny>
From: Allan Erskine <a.erskine@cs.ucl.ac.uk>
To: cocoon-dev <cocoon-dev@xml.apache.org>
References: <NEBBLPMLKKCJBKEOKNFHCEBBEAAA.cziegeler@sundn.de>
Subject: Re: cvs commit: xml-cocoon/webapp/docs/samples/xsp cookie.xsp
Date: Thu, 19 Apr 2001 14:40:06 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> I think, this are two different tasks, the first is database access and
the
> second is redirection. For generating content, XSP Taglibs are very very
> valuable. There is no doubt about it. But I personally see XSP (currently)
> only on the content side and not on the webapp flow (see below).

>From the thread XSP and aspects a month or two ago, Ricardo voiced the
opinion that separating the sitemap generating mechanism from XSP was a big
mistake, and AFAIR it was concluded that it would be advantageous if the
sitemap were brought back under (a suitably restricted) XSP's remit.  So XSP
should perhaps be considered for webapp flow.

In my opinion this goes for a number of other C2 components, in particular
actions.  Implementing an XML->action compilation mechanism would seems
ludicrous as it would invariably be XSP-like.....I would like to view XSP as
the single canonical language for configuring and representing the state
structure for all dynamic components in an XML server environment, but I
don't know if this view is widely held.

If a superior XSP processing pipeline mechanism could be implemented, then
in the first instance, sitemaps and serverpages could be generated in the
same way, work could begin on the flowmap, and actions and other components
could enjoy from all XSP's wonderful dimensionality reducing features.  A
large majority of users have experience with tag-libs, and will be
immediately overawed by the potential of Cocoon if it became an XSP platform
on this scale.  As it is, I agree there will be a lot of head-scratching
going on over java actions as they stand.

And going back to the flowmap (I think a lot of us know we want one, but
aren't sure how to get it); if a flowmap and the sitemap were both XSP
taglibs, people would take to the idea like ducks.  Imagine the potential of
the flowmap guiding the application flow from state to state, with sitemap
constructs shifting the URI landscape accordingly within the same XSP file.
<flow:this> <map:that>  Sitemap URI's wouldn't even exist until the
application was in the correct flow-state.  To users from an XSP background,
it would seems the most natural thing in the world to see these two hugely
powerful taglibs come together in one file.

(Ricardo says he's been working on ideas for a component composition
mechanism which could potentially realise this sort of application.  I hope
it wouldn't be too presumptious to suggest that he'd be very happy if more
people came round to this viewpoint)

So my position is:  XSP for sitemaps, serverpages, flowmaps, actions,
aspects.

I have a web-app currently eating into my time (was supposed to be finished
2 weeks ago, all that writing java actions!) but after that I'd like to
commit myself to just such a project.

- Allan
----- Original Message -----
From: "Carsten Ziegeler" <cziegeler@sundn.de>
To: "cocoon-dev" <cocoon-dev@xml.apache.org>
Sent: Thursday, April 19, 2001 1:31 PM
Subject: AW: cvs commit: xml-cocoon/webapp/docs/samples/xsp cookie.xsp


> Jeremy Quinn wrote:
>
> At 6:24 PM +0200 18/4/01, giacomo wrote:
> >> So as another example what if we want to redirect to a value that is
> >> returned from a database call... where the user wants to use esql
> >> (beacuse it is *simple*) to retirve the value from the database? how is
> >> that redirect passed back to the sitemap?
> >
> >Never! It's a bad use case IMHO. Use an action to handle you DB-redirect
> >stuff with the help of the sitemap.
>
> So what that means is that esql and all other XSP TagLibs get de-valued.
>
> For example, people who want to access databases in a webApp that might
> require redirect functionality, are forced to write (and
> maintain) their DB
> access code in Java rather than using the far simpler esql language, as
> they could in C1.
>
I think, this are two different tasks, the first is database access and the
second is redirection. For generating content, XSP Taglibs are very very
valuable. There is no doubt about it. But I personally see XSP (currently)
only on the content side and not on the webapp flow (see below).

> This is a very different scenario and for many people will be a
> non-trivial
> difference between the two environments.
>
> This is why I suggested earlier that some way be found to compile Actions
> from XML like happens with XSP and generators, so that non-java
> programmers
> can once again leverage the power of TagLibs that they loose by moving to
> C2.
>
I agree, that compiling Actions from XML would be very handy (like the
Script Action, proposed yesterday). Perhaps this might be solution out of
this problem as the actions are very important components which currently
are only createable with java-knowledge.
So +1 for this...


regards Carsten

Open Source Group                        sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de                          mailto: cziegeler@sundn.de
================================================================


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org