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
