You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Davanum Srinivas <di...@yahoo.com> on 2001/04/19 17:06:35 UTC
[C2] XSP based Action (was Re: cvs commit: xml-cocoon/webapp/docs/samples/xsp cookie.xsp)
Allan,
+1 for taking a shot @ XSP based actions.
Thanks,
dims
--- Allan Erskine <a....@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" <cz...@sundn.de>
> To: "cocoon-dev" <co...@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" <cz...@sundn.de>
> > To: "cocoon-dev" <co...@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
Re: [C2] XSP based Action
Posted by Berin Loritsch <bl...@apache.org>.
Jeremy Quinn wrote:
>
> At 2:00 PM -0400 19/4/01, Berin Loritsch wrote:
> >Jeremy Quinn wrote:
>
> >> When I get back, I start work writing our new Crudlet 2.0 TagLib, the first
> >> thing I'll be asking advice about, will be ....
> >>
> >> What is the best way to write the XMLFragment implementing support
> >> objects for a TagLib so that you do not have to write output code for both
> >> DOM and SAX?
> >>
> >> As Cocoon 2 is the future, it makes sense to me to "natively"
> >>output SAX
> >> Events, and have some sort of "adapter" to capture the events and convert
> >> them to DOM for output to Cocoon 1. (the opposite of DOMStreamer?)
> >>
> >> Does this make sense?
> >>
> >> Is it possible?
> >
> >Is this something you can accomplish using <xsp:element> and <xsp:attribute>?
> >If that is the case, then let Cocoon do the hard work for you.
>
> Hi Berin,
>
> Thanks for the reply, I've just got back .....
>
> It is just too complex, I think it would be possible if I only had Simple
> Properties but I have to be able to recurse through Beans and their
> Composite Properties (Beans that contain Beans) etc, building XML that
> represents the Bean/Property structure.
>
> Any other suggestions?
It's been a while, so I will venture this approach that I have used:
I have my beens implement an XMLizable interface that has two methods:
interface XMLizable {
String toXML();
void toSAX(ContentHandler handler);
}
If a bean has a child bean, they use Cocoon's contenthandler for includes
(strips start and end document events). This ensures that every bean is
represented in a clear and consistent manner--no matter the context.
The reason for the two methods is that when you are communicating over a
wire (i.e. EJB), SAX is too costly. Otherwise, SAX is the preferred method,
and is directly embeddable in Cocoon.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] XSP based Action
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 2:00 PM -0400 19/4/01, Berin Loritsch wrote:
>Jeremy Quinn wrote:
>> When I get back, I start work writing our new Crudlet 2.0 TagLib, the first
>> thing I'll be asking advice about, will be ....
>>
>> What is the best way to write the XMLFragment implementing support
>> objects for a TagLib so that you do not have to write output code for both
>> DOM and SAX?
>>
>> As Cocoon 2 is the future, it makes sense to me to "natively"
>>output SAX
>> Events, and have some sort of "adapter" to capture the events and convert
>> them to DOM for output to Cocoon 1. (the opposite of DOMStreamer?)
>>
>> Does this make sense?
>>
>> Is it possible?
>
>Is this something you can accomplish using <xsp:element> and <xsp:attribute>?
>If that is the case, then let Cocoon do the hard work for you.
Hi Berin,
Thanks for the reply, I've just got back .....
It is just too complex, I think it would be possible if I only had Simple
Properties but I have to be able to recurse through Beans and their
Composite Properties (Beans that contain Beans) etc, building XML that
represents the Bean/Property structure.
Any other suggestions?
Thanks
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] XSP based Action
Posted by Berin Loritsch <bl...@apache.org>.
Jeremy Quinn wrote:
>
> At 5:11 PM +0100 19/4/01, Allan Erskine wrote:
> >
> >Any thoughts? The first way seems easiest...
> >
> >Allan
>
> Thanks Allan, this is going to be very cool!
> Just when the discussion gets interesting, I am off for a weeks holiday ;>
>
> When I get back, I start work writing our new Crudlet 2.0 TagLib, the first
> thing I'll be asking advice about, will be ....
>
> What is the best way to write the XMLFragment implementing support
> objects for a TagLib so that you do not have to write output code for both
> DOM and SAX?
>
> As Cocoon 2 is the future, it makes sense to me to "natively" output SAX
> Events, and have some sort of "adapter" to capture the events and convert
> them to DOM for output to Cocoon 1. (the opposite of DOMStreamer?)
>
> Does this make sense?
>
> Is it possible?
Is this something you can accomplish using <xsp:element> and <xsp:attribute>?
If that is the case, then let Cocoon do the hard work for you.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] XSP based Action
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 5:11 PM +0100 19/4/01, Allan Erskine wrote:
>
>Any thoughts? The first way seems easiest...
>
>Allan
Thanks Allan, this is going to be very cool!
Just when the discussion gets interesting, I am off for a weeks holiday ;>
When I get back, I start work writing our new Crudlet 2.0 TagLib, the first
thing I'll be asking advice about, will be ....
What is the best way to write the XMLFragment implementing support
objects for a TagLib so that you do not have to write output code for both
DOM and SAX?
As Cocoon 2 is the future, it makes sense to me to "natively" output SAX
Events, and have some sort of "adapter" to capture the events and convert
them to DOM for output to Cocoon 1. (the opposite of DOMStreamer?)
Does this make sense?
Is it possible?
I would ideally want to do this in a way that does not require Both Cocoon
1 and 2 to be able to compile the XMLFragment Objects.
Any suggestions would be welcome, but you won't hear from me for a week.
thanks
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] XSP based Action (was Re: cvs commit:
xml-cocoon/webapp/docs/samples/xsp cookie.xsp)
Posted by giacomo <gi...@apache.org>.
Carefull guys. The XSP syntax and semantic will not be discussed in this
list. It is out of scope for Cocoon because of other implementations of
XSP (AxKit). Go discuss this on the xsp-dev list.
Giacomo
On Thu, 19 Apr 2001, Allan Erskine wrote:
> Here's two possible approaches: an XSP action root element, or namespace
> introduction.
>
> With a root element, we could use that to fix what type of component gets
> generated, so that <xsp:page> produces XSPGenerator components, <xsp:action
> ....> produces Actions. Within the XSP action page body it should be
> possible to use the other taglibs as before, as they ought to be made
> agnostic as to why they're producing XML, or performing queries in esql's
> case.
>
> Namespace introduction seems to be a bit more subtle, but it was the way
> some people, notably Stephano, Matt, and Ricardo, seemed to envisage things
> going. Here an XSP file needs no root element (and embedded code is
> disabled without explicitly being enabled), and taglibs are brought in
> through namespace introduction as appropriate eg
>
> <?xml?>
> <content>
> <p xmlns:xsp-request="........">The request was <xsp-request:get-parameter
> ...../>
> </p>
> <xsp-request:get-parameter>this element gets output as is, since it's not in
> the namespace scope.
> </xsp-request:get-parameter>
> </content>
>
> This reflects a duality of purpose in the way almost all xsp tags are used.
> On the one hand they configure some code, on the other hand they produce
> some XML. I see nothing wrong with this; it seems just a natural
> consequence of wanting to produce XML dynamically.
>
> So here taglibs would declare what interfaces they could be called through
> (in cocoon.xconf), and those which didn't could be used generically (ie just
> to produce XML). We'd need at least one action specific taglib used
> somewhere in an XSP file for the generated component to implement the Action
> interface (and be used as an action within the sitemap).
>
> We'd probably find most XSP components would have some XML part representing
> the state of the component (in a serverpage this is the predominant part),
> so for this approach I'd be tempted to extend all XSP components from
> XSPGenerator, and to implement different interfaces depending on the taglibs
> used within. The semantics of generating a component other than a
> serverpage would be to access the state of that component in a pipeline (for
> administrative purposes say).
>
> Of course there's probably a bit more room for confusion this way as it
> breaks cohesion.
>
> Any thoughts? The first way seems easiest...
>
> Allan
>
> ----- Original Message -----
> From: "Davanum Srinivas" <di...@yahoo.com>
> To: "cocoon-dev" <co...@xml.apache.org>
> Sent: Thursday, April 19, 2001 4:06 PM
> Subject: [C2] XSP based Action (was Re: cvs commit:
> xml-cocoon/webapp/docs/samples/xsp cookie.xsp)
>
>
> > Allan,
> > +1 for taking a shot @ XSP based actions.
> >
> > Thanks,
> > dims
> >
> > --- Allan Erskine <a....@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" <cz...@sundn.de>
> > > To: "cocoon-dev" <co...@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" <cz...@sundn.de>
> > > > To: "cocoon-dev" <co...@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
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: [C2] XSP based Action (was Re: cvs commit:
xml-cocoon/webapp/docs/samples/xsp cookie.xsp)
Posted by Allan Erskine <a....@cs.ucl.ac.uk>.
Here's two possible approaches: an XSP action root element, or namespace
introduction.
With a root element, we could use that to fix what type of component gets
generated, so that <xsp:page> produces XSPGenerator components, <xsp:action
....> produces Actions. Within the XSP action page body it should be
possible to use the other taglibs as before, as they ought to be made
agnostic as to why they're producing XML, or performing queries in esql's
case.
Namespace introduction seems to be a bit more subtle, but it was the way
some people, notably Stephano, Matt, and Ricardo, seemed to envisage things
going. Here an XSP file needs no root element (and embedded code is
disabled without explicitly being enabled), and taglibs are brought in
through namespace introduction as appropriate eg
<?xml?>
<content>
<p xmlns:xsp-request="........">The request was <xsp-request:get-parameter
...../>
</p>
<xsp-request:get-parameter>this element gets output as is, since it's not in
the namespace scope.
</xsp-request:get-parameter>
</content>
This reflects a duality of purpose in the way almost all xsp tags are used.
On the one hand they configure some code, on the other hand they produce
some XML. I see nothing wrong with this; it seems just a natural
consequence of wanting to produce XML dynamically.
So here taglibs would declare what interfaces they could be called through
(in cocoon.xconf), and those which didn't could be used generically (ie just
to produce XML). We'd need at least one action specific taglib used
somewhere in an XSP file for the generated component to implement the Action
interface (and be used as an action within the sitemap).
We'd probably find most XSP components would have some XML part representing
the state of the component (in a serverpage this is the predominant part),
so for this approach I'd be tempted to extend all XSP components from
XSPGenerator, and to implement different interfaces depending on the taglibs
used within. The semantics of generating a component other than a
serverpage would be to access the state of that component in a pipeline (for
administrative purposes say).
Of course there's probably a bit more room for confusion this way as it
breaks cohesion.
Any thoughts? The first way seems easiest...
Allan
----- Original Message -----
From: "Davanum Srinivas" <di...@yahoo.com>
To: "cocoon-dev" <co...@xml.apache.org>
Sent: Thursday, April 19, 2001 4:06 PM
Subject: [C2] XSP based Action (was Re: cvs commit:
xml-cocoon/webapp/docs/samples/xsp cookie.xsp)
> Allan,
> +1 for taking a shot @ XSP based actions.
>
> Thanks,
> dims
>
> --- Allan Erskine <a....@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" <cz...@sundn.de>
> > To: "cocoon-dev" <co...@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" <cz...@sundn.de>
> > > To: "cocoon-dev" <co...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org