cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: cvs commit: xml-cocoon/webapp/docs/samples/xsp cookie.xsp
Date Thu, 19 Apr 2001 14:39:15 GMT
> Allan Erskine wrote
> 
> > -1 for XSP for sitemaps as we shouldn't change the concept at 
> this stage.
> The
> > sitemap is working very well and you don't really have to worry 
> about any
> > programming language (like Java for XSP etc) to "write" your sitemap.
> 
> AFAIR the idea was that all programming constructs in an XSP page 
> were bad,
> so we'd disable it by default for all XSP components apart from 
> serverpages
> (to maintain compatibility).  The sitemap syntax would remain completely
> unchanged.
> 
Ah, ok this changes something. If there would be no difference for the 
sitemap writer, XSP is ok. I don't want to start the old discussion again,
but I don't see any advantage in using XSP then for the sitemap as well.
We have a good working solution.

But of course we could prove if we should change the sitemap generation
for a next release, but I don't want to change it for the first C2 release.

regards Carsten

> Only the sitemap generating mechanism would change.  It would become
> rationalised with a general purpose XSP component generation and 
> compilation
> mechanism.  Ricardo was all for XSP sitemaps, and regarded it as a blunder
> that they were separated (he pointed this out in the XSP and aspects
> thread).
> 
> Allan
> 
> ----- Original Message -----
> From: "Carsten Ziegeler" <cziegeler@sundn.de>
> To: "cocoon-dev" <cocoon-dev@xml.apache.org>
> Sent: Thursday, April 19, 2001 2:51 PM
> Subject: AW: cvs commit: xml-cocoon/webapp/docs/samples/xsp cookie.xsp
> 
> 
> > 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.
> >
> > 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.
> >
> +1 for XSP for serverpages
> +1 for XSP for actions
> don't know for XSP for flowmaps
> -1 for XSP for sitemaps as we shouldn't change the concept at this stage.
> The
> sitemap is working very well and you don't really have to worry about any
> programming language (like Java for XSP etc) to "write" your sitemap.
> 
> > 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.
> >
> Great, we should see how this fits to our beta release date.
> 
> regards Carsten
> 
> 
> ---------------------------------------------------------------------
> 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