Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <475A64DC.7050402@apache.org>
Date: Sat, 08 Dec 2007 10:33:16 +0100
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] RESTful web applications
References: <20071129220613.180721A9832@eris.apache.org>
 <474F3A70.6070001@apache.org> <474F4D69.7070704@apache.org>
 <474FBE76.60407@apache.org> <474FC59D.1050201@apache.org>
 <474FD147.3000900@apache.org> <4750860A.9000208@apache.org>
 <475097CB.7050909@apache.org> <47515570.3040809@apache.org>
 <4751E490.4010200@apache.org> <47522278.80601@dslextreme.com>
 <4752C9C7.1010809@apache.org> <4752FB4C.3050808@dslextreme.com>
 <47549C3B.2060004@apache.org> <4754C078.9030408@dslextreme.com>
 <475503FA.5070700@apache.org> <475506A4.7090308@dslextreme.com>
 <47550CAC.1030206@apache.org> <475683C9.20705@apache.org>
 <4756A0EB.5000500@apache.org> <4756AA48.6090609@apache.org>
 <4756B2B0.1010206@apache.org> <4757DBE2.8020406@apache.org>
In-Reply-To: <4757DBE2.8020406@apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Sylvain Wallez wrote:
> Reinhard Poetz wrote:
>> Recently I've been thinking more and more about some kind of
>> "Micro-Cocoon"[*] that consists of
>>
>>  o a slimmed-down sitemap language available in as an XML and as a
>> Java dialect
>>    (no component declarations, no sub-sitemaps, no resources, merged
>>     match/select),
> 
> I wrote a simple Java library about 2 years ago (time flies!) that
> mimics the major features of the sitemap: pattern matching and variable
> substitution calling plain old servlets rather than pipelines. Not more
> than a dozen of classes :-)

Sounds interesting. We haven't decided it yet, if we really go the way of 
working on a "Micro-Cocoon", but if we do so we will definitly share our 
thoughts and findings with this list and I hope that you can share your 
experiences with us then.

>>  o a controller implementation that is optimized for being used in
>> RESTful
>>    scenarios (similar to Apples) and
>>  o a lean forms framework that borrows some ideas from Webforms 2.0 and
>>    follows the principles of REST. Daniel and I had some discussions
>> about it in
>>    Rome and I've started with some experiments but don't have anything
>>    substantial so far.
>>
>> All the parts mentioned above should be useable in parallel with a
>> traditional Cocoon 2.2 application. Thanks to the servlet-service
>> framework this shouldn't be too hard to be achieved.
>>
>> If this sounds interesting to anybody, just let me know.
> 
> It does sound interesting. Now I'm wondering if XML pipelines still fit
> in the web application landscape. They are perfect for publication
> purposes, but webapps nowadays have been completely infected by Ajax
> and/or components approaches.
>
> On one hand, component-oriented approaches like GWT or Wicket
> essentially hide the HTTP protocol in favor of application-level Java
> code, and on the other hand the use of pure Ajax libraries such as Dojo,
> YUI, Ext and the like leads the browser to become a REST client using
> plain XML or JSON responses.

yes, agreed

>>>From a REST point of view, this dichotomy is interesting since
> component-oriented approaches ignore REST principle while Ajax libraries
> more or less require to design applications as a set of REST services,
> thus making them almost ready for machine clients.
> 
> But in both cases, XML pipelines are not really needed anymore IMHO,
> except as you mention to aggregate remote sources. But it is then more a
> concern of the business-logic side of the application rather than that
> of the part handling client requests.

In our case we have to provide several (similar) representation formats 
(different views and/or output formats) of one and the same resource. We could 
either do it by writing additional templates or by using XML transformations. 
Since we are fluent in XSLT, this is by far the most productive way _for us_ to 
implement it.

> About the limitations of current browsers wrt to the full set of REST
> features (e.g. methods other than POST and GET), the book "Restful Web
> Services" [1] proposes a number of interesting workarounds such as using
> a request parameter (which can be a hidden form field) to override some
> headers or complement the request. 

yes, RoR solves this problem this way, AFAIK.

> We could imagine a simple request
> filter that interprets these workarounds to present the servlets with
> the real "pure" REST requests.

good idea

-- 
Reinhard Pötz                            Managing Director, {Indoqa} GmbH
                           http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair        reinhard@apache.org
_________________________________________________________________________