cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <d...@yahoo.com>
Subject [C2] XSP based Action (was Re: cvs commit: xml-cocoon/webapp/docs/samples/xsp cookie.xsp)
Date Thu, 19 Apr 2001 15:06:35 GMT
Allan,
+1 for taking a shot @ XSP based actions. 

Thanks,
dims

--- Allan Erskine <a.erskine@cs.ucl.ac.uk> wrote:
> > 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.
> 
> Yes, of course...Ricardo was talking about a fairly hefty overhaul of the
> XSP mechanism.  You're right that this shouldn't get in the way of all the
> great work you've been doing.  And SiLLy was also part of the plan for the
> new mechanism...
> 
> In the longer term though, I think an XSP sitemap makes a lot of sense.
> 
> What about XSP actions though?  It strikes me that they could be implemented
> without getting in anyone's way, and it would be a good practise ground for
> ramping up XSP's role in the future, if we decide that's the way to go.
> 
> I'd be happy to muck in and help do this.
> 
> Allan
> 
> ----- Original Message -----
> From: "Carsten Ziegeler" <cziegeler@sundn.de>
> To: "cocoon-dev" <cocoon-dev@xml.apache.org>
> Sent: Thursday, April 19, 2001 3:39 PM
> Subject: AW: cvs commit: xml-cocoon/webapp/docs/samples/xsp cookie.xsp
> 
> 
> > 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
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 


=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

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


Mime
View raw message