Reinhard Poetz wrote: > Sylvain Wallez wrote: >> Reinhard Poetz wrote: >> >> <snip/> >> >>> For me those are the reasons why I said that I have changed the camp >>> and think that Stefano was right with his opinion that traditional web >>> frameworks would become obsolete. But, in contrast to him, I think >>> that Cocoon, which in some respect isn't 'traditional' at all, can >>> become the ideal server-side counterpart for such RESTful web >>> applications. >> >> Interesting! Can you elaborate on why you think Cocoon is great for >> RESTful applications? Is it because of its URL pattern matching >> features? > > That's one half of the story. The other one is XML pipelines and > content aggregation on an XML level (XML plays in many RESTful > architectures an important role, at least in ours) which make Cocoon > still very appealing to me. Actually all three together are the virus > that has infected me long time ago at the good old Cocoon 2.0alphaX days. > > - o - > > 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 :-) > 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. >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. WDYT? 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. We could imagine a simple request filter that interprets these workarounds to present the servlets with the real "pure" REST requests. Sylvain [1] http://www.oreilly.com/catalog/9780596529260/ -- Sylvain Wallez - http://bluxte.net
