[
Lists Home |
Date Index |
Thread Index
]
>>
I've been interested in trying out RESTful design principles for Cocoon
applications.
It's currently my environment of choice for cobbling together web
applications
and demonstrators.
There's a SOAP logicsheet in Cocoon also, which many folk have used
to integrate with the Google API from within XSP page. However if Google
had offered a RESTful API, similar to that which Paul described in his
article, this would be unnecessary as you'd just use a normal Cocoon
Generator.
Which from a Cocoon perspective is very simple indeed.
<<
You can also use the Cinclude Transformer - for GETs and the session
transformer for PUTs (see also:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=102033433627214&w=2).
Cocoon has it all :-)
Matthew Langham
--
Open Source Group Cocoon { Consulting, Training, Projects }
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
-----------------------------------------------------------------
Cocoon book:
http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
=================================================================
-----Original Message-----
From: Leigh Dodds [mailto:ldodds@ingenta.com]
Sent: Tuesday, May 07, 2002 11:14 AM
To: Michael Leditschke; Didier PH Martin
Cc: xml-dev@lists.xml.org
Subject: [xml-dev] RE: Cocoon and "accept" request WAS "RE: [xml-dev]
Call for example of server enabled for XML multiple representations"
> -----Original Message-----
> From: Michael Leditschke [mailto:mike@ammd.com.au]
> Sent: 07 May 2002 01:18
> To: Didier PH Martin
> Cc: xml-dev@lists.xml.org; ldodds@ingenta.com
> Subject: Cocoon and "accept" request WAS "RE: [xml-dev] Call for example
> of server enabled for XML multiple representations"
> ...
> From my reading of the doco, the component in Cocoon 2 to do what
> you say is a selector.
> ...
> Alternatively, if designing a logicsheet, you can access all the request
> information via the built-in "request" environmental logicsheet.
Yep, both of those will work. The advantage in the Selector approach
is that you can make the Cocoon pipeline conditional on the header
information, which is much more flexible. While you can do this
with the request logicsheet, it'll make the XSP pages, and downstream
XSLT processing more complex.
I've been interested in trying out RESTful design principles for Cocoon
applications.
It's currently my environment of choice for cobbling together web
applications
and demonstrators.
There's a SOAP logicsheet in Cocoon also, which many folk have used
to integrate with the Google API from within XSP page. However if Google
had offered a RESTful API, similar to that which Paul described in his
article, this would be unnecessary as you'd just use a normal Cocoon
Generator.
Which from a Cocoon perspective is very simple indeed.
> <aside>
> I have found the ibm developerworks tutorials on Cocoon excellent and a
> great introduction if, like me, you are starting from zero. Thanks Leigh!
> </aside>
Thanks! There's a third still to appear (on database integration).
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
