cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: RESTapples
Date Fri, 16 Mar 2007 14:24:17 GMT
Reinhard Poetz skrev:
> Daniel Fagerstrom wrote:
>> Spring actions
>> ==============
>>
>> With AJAX it is much easier to have a stateless web server as 
>> backend. But Cocoon's "recommended" controllers: Flowscripts and 
>> Javaflow main focus is on session based servers. And Cocoon actions 
>> isn't exactly the most exciting technology around.
>>
>> I'd like actions that embrace dependency injection, doesn't need to 
>> implement some obscure interface and that can be easily used with a 
>> reloading classloader. IMO the action part of Struts2 
>> (http://www.infoq.com/articles/converting-struts-2-part1) has a lot 
>> of god ideas. Either we could try to make it possible to use the 
>> Struts2 action framework as Cocoon actions or steal some of their ideas.
>>
>> REST
>> ====
>>
>> Gianugo has evangelized using Cocoon as a REST framework (couldn't 
>> find any link though). Steve Loughran says that the Cocoon folk has a 
>> better idea about what to do in the REST area than the WS projects: 
>> http://www.1060.org/blogxter/entry?publicid=8C08746C8C0462CC6FB4E4D69098F1AE. 
>> That is soomething to live up to ;)
>>
>> Cocoon already have a lot of what is needed but lacks e.g. a 
>> mechanism for content negotiation and ETags support and more work is 
>> needed on return codes. What especially is lacking is REST samples 
>> and a tutorial on how to use Cocoon as a REST web service server.
>
> I've been working on rest block that is based on Apples. It won't do 
> much but to provide a controller interface that extends the 
> StatelessApplesController
>
> public interface RestApple extends StatelessAppleController {
>
>     void doGet(AppleRequest req, AppleResponse res) throws Exception;
>
>     void doPost(AppleRequest req, AppleResponse res) throws Exception;
>
>     void doPut(AppleRequest req, AppleResponse res) throws Exception;
>
>     void doDelete(AppleRequest req, AppleResponse res) throws Exception;
>
> }
>
> and provides an abstract implementation. Based on the method of the 
> incoming http request, one of the 4 methods is invoked. Currently this 
> switch is implemented in the AbstractRestApple but should be moved to 
> the Apples processor.
One of my main learning from the Cocoon projects is that I have become 
severely allergic against depending on tons of interfaces, classes and 
libraries ;)

So while the above might look innocent enough I'm not exactly thrilled 
by the thought of letting all my controllers extend some abstract class 
and use some questionable interfaces. Take a look at 
http://jra.codehaus.org/ and 
http://weblogs.java.net/blog/mhadley/archive/2007/02/jsr_311_java_ap.html 
and compare.

For my controller I'd like to inject the dependencies that I want and 
not having anything to do with some "object model" etc.

> If we worked on the Apples processor, we could even drop the 
> requirement of implementing an interface and do the same like Struts 2.
Yes.
> But I wonder what we gain except from being more modern,
That is an important gain in itself. But what is more important is that 
people will get up to speed faster if we are close to what they would 
expect.
> if we used annotations (actually it doesn't bring much because you 
> still have to add an import statement for the annotation) or a 
> reflection mechanism to determine which method to execute ;-)
The point is that by using annotations you don't get the configuration 
spread out. And by using "convention over configuration", you will not 
need any annotations if you follow the recommended idioms.

/Daniel


Mime
View raw message