Andrea Aime wrote:
The only web frameworks that can do both UI and REST calls are the
action based ones, in a component based one (Wicket, JSF) web services
have nothing to do with UI building, whilst in an action based one
you're throwing out a document in response to a call so they can
be coaxed to do REST as well.
Hmm... I don't see it as a component vs action issue, but as a
consequence of the scope of a framework: GWT, Wicket and JSF are for
building web-based UIs and handling the flow of pages (Wicket and GWT
are for *hiding* the building of web-based UIs, actually), while Struts
and others have the ambition of covering the whole of a web application.
The only framework I know about that can do both UI and REST
is, as you stated, Struts2, with this plugin: http://struts.apache.org/2.x/docs/rest-plugin.html.
So if this is a strong requirement, then the UI evaluation is
pretty much done, we're left with just one candidate (or maybe
two? can Cocoon do both UI and REST api?
Well, in my eyes, a framework doesn't *do* REST: since REST is just a style of arranging the URI space and using the whole set of HTTP methods as they were intended originally, any web framework should do.
Having said that, framework like Struts2 (via the plugin you mentioned) and RESTlet let you directly connect URI to Java classes methods, while Cocoon has an intermediate layer (the sitemap) for routing URIs: you may see this either as added complexity or increased flexibility 
can it emit json?).
Yes, Cocoon can emit JSON from Flowscript (Java objects of certain type
are serialized as JSON and sent do the client), there is even a JSONSerializer, but it never made past the prototype stage.
Another thing that I was thinking about is the point that Arne
raised during yesterday's meeting about the current UI looking
bad and being clearly designed by a Java programmer as opposed
by an interaction designer.
A Java programmer can build good UIs too, I suspect.
Look, I've never heard of a "saw craftsman" as unable to make an elegant wood table: let's separate the tool from the product.
An UI that does both REST and web pages has to behave like a
service framework anyways, so I guess this leaves no room at
all for an interaction designed to impose a different UI
workflow?
I presume you could still have your UI built in Wicket and your REST API in, say, Struts 2, but these would leave Struts underutilized.
This seems to me like something requiring the REST
API to be separated from the UI?
Actually, if you are serious about REST, no state should be on the server, hence calling for a pure AJAX client.
Of course, a pure AJAX client has problems of its own (I still don't see Javascript as a solid foundation, but I may be just scarred from the use of Javascript in those dark pre-AJAX days).
Regards,
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
