cocoon-dev 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: cvs commit: xml-cocoon/webapp/docs/samples/xsp cookie.xsp
Date Thu, 19 Apr 2001 22:23:02 GMT
I'll keep this as a cocoon issue....no need to cross post.  The last time I
talked to Matt we agreed that we could do whatever we liked without changing
XSP, and also this is specific to cocoon.

> 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

Sorry for not being clear - my understanding of XSP is more b).  I'd rather
see the actual mark-up language side of XSP a) (ie the contents of the XSP
logic-sheet) used as little as possible, as it allows too many hairy
programming constructs.

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

This is why I've found the distinction to have become blurred I guess.

My only thought was that it's XSP in everything but name, which doesn't seem
to make sense.  This is why instead of trying to delimit boundaries between
what is and isn't XSP even though it looks the same, I think just be done
with it and allow everyone to enjoy a powerful technique for all purposes
under one banner.  It's good to have unity of concept, but so long as it
get's the job done I guess it doesn't matter too much what we call it.

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

I'm with you on both counts here, love SoC I do.  The last thing I'd want to
see would be, say, esql tags updating a database in the sitemap file.
Although I can imagine flowmap and sitemap tags coexisting, as the flow of
an application determines what URI space is available to navigate to (I
concede this could also be done quite happily in separate mechanisms too).

I think the XML->Java system would be very useful decoupled from Cocoon, and
you never know, if some CMS or other adopted it, it would be a peach to
integrate...

So my new position would be:  a single, rationalised, XML->server component
mechanism for serverpages, sitemaps, flowmaps, actions, aspects (call it
EXSP perhaps).

Are people still interested in actions going this way sooner rather than
later (whether or not called XSP)?  I'm undecided - while I think it would
be useful to explore the possibilities, it may be unwise to spread the
codebase further by tweaking the existing XML->component mechanism to cover
3 similar but different bases (serverpages, sitemaps + actions).

Could one of you experts take a guess at how difficult this might be?  If
it's a large job then it may be better to wait for what Ricardo has to say,
as I gather he's been thinking a lot about this.

Allan

----- Original Message -----
From: "giacomo" <giacomo@apache.org>
To: "cocoon-dev" <cocoon-dev@xml.apache.org>
Sent: Thursday, April 19, 2001 9:05 PM
Subject: Re: cvs commit: xml-cocoon/webapp/docs/samples/xsp cookie.xsp


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


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


Mime
View raw message