Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Thu, 19 Apr 2001 22:05:57 +0200 (CEST)
From: giacomo <giacomo@apache.org>
To: cocoon-dev <cocoon-dev@xml.apache.org>
Subject: Re: cvs commit: xml-cocoon/webapp/docs/samples/xsp cookie.xsp
In-Reply-To: <002d01c0c8d6$3fb27370$ea4dfea9@spukny>
Message-ID: <Pine.LNX.4.31.0104192149170.1379-100000@lap1.otego.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Thu, 19 Apr 2001, Allan Erskine wrote:

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

I've never really undestud that point. What do you mean when you say
XSP? Is it

a) the markup-language
b) the system which does XML->Java

On a) I'd like to say that XSP was made to represend an XML document
enriched with logic to produce that XML document. In this sense neither
Actions nor the sitemap are such things.

On b) the sitemap code generation *does* use the implemented XML->Java
system and it does so from the very beginning of the implementation of
the generated sitemap.

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

I would say that such an XML->Action "markup-language" is like the
sitemap a different one from XSP.

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

There is not technical problem using taglibs for the sitemap but IMHO it
does not make any sence (SoC). It may make sense for XML->Action
stuff. What I really would like to see is a decoupling of the
XML->Java system from Cocoon so that it can be used inside *and* outside
of Cocoon maybe as a commandline "compiler" able to transform different
markup-languages into java classes.

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

Also for flowmaps I can see this could be implemented as a different
"markup-language" and compiled into a java class by the XML->Java system

> (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)

I thought it was already available at the bibop site?

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

-1 XSP for sitemaps (XSP is not the right markup-language)
 0 XSP for serverpages (already the case)
-1 XSP for flowmaps (same as sitemap)
-1 XSP for actions (an Action is not generatin any XML so XSP is of
                    no use here)
?  XSP for aspects (no idea what this should be al about but I guess
                    that also here XSP is not the right markup-language
                    for it).

Giacomo


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


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