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 -------------------- ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
