You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2007/03/16 08:12:42 UTC
RESTapples
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.
If we worked on the Apples processor, we could even drop the requirement of
implementing an interface and do the same like Struts 2.
But I wonder what we gain except from being more modern, 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 ;-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: RESTapples
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>> 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;
>
> Given the recent crusade against Cocoon environment, I gotta ask, why
> 'RestApple' and not 'Servlet'; why 'AppleRequest' and not 'ServletRequest'?
because I want to write a Cocoon REST server now without having to reinvent Cocoon.
> I'm sure Daniel will support this question too ;-)
LOL, I think so too.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: RESTapples
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> 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;
Given the recent crusade against Cocoon environment, I gotta ask, why
'RestApple' and not 'Servlet'; why 'AppleRequest' and not 'ServletRequest'?
I'm sure Daniel will support this question too ;-)
Vadim
Re: RESTapples
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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