On Mon, Aug 25, 2008 at 12:54 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: > Another option is a client-side component-based framework like Ext or Flex > running directly against web services, RESTful or otherwise. No server-side > web framework required. Of course, you could use something server-side like > DWR to facilitate working with web services, or Jersey for RESTful services, > but that would be a choice rather than a requirement.
This is a nice design, when you can do it. GWT is also a good way to build these types of apps. Unfortunately, they can easily break much of what makes the web what it is - the back button, unique, addressable URI's, accessibility, search engine crawling, etc. Therefore, I think some sort of server-side web framework will usually be necessary, however, I don't think it has to go so far as JSF, where they try to push all the state to the server. I was talking with a guy here at work who is looking to start using GWT more about how and where a plain HTML view of the application fits. He wants to do very dynamic, client-side heavy views, but still needs to support search engines and REST clients. What if you use Jersey for your REST API, GWT or straight JQuery for your client-side UI, then have Jersey + something generate HTML views of your REST API, which you could use for search engines and developers wanting to browse and interact with your application. If you can have the HTML representation of your REST API auto-generated, you wouldn't have to maintain two different interfaces, and you could go fully nuts with your client-side heavy app without having to worry about accessibility or search engine issues. Don > > -- > Martin Cooper > > > This idea of a JSR would be standardizing the third group, but I >> wonder if maybe the better direction to go is not a new API, but build >> extensions on JAX-RS [2]. To me, this group's niche is apps that need >> lightweight presentation engines a layer above servlets, but still >> very much "web-y". JSR 311 aims to make restful resources easy to >> build, which isn't far from restful web applications. Especially as >> more and more applications are starting to rely on client-side AJAX >> interfaces, the need for a solid RESTful backend only gets stronger. >> The storage of server-side state of the component frameworks becomes >> less important, and if you don't want the bulk of Grails, this >> approach may be attractive. >> >> For my day job, we need to build REST interfaces to our web apps, so >> we are looking to standardize on JAX-RS. Well, we also need a >> lightweight web framework for our plugin system, and if we are already >> using something like Jersey [3], it would be nice to be able to write >> web apps using the same technology. This use case is obviously very >> specific to our situation, but it is the direction I'll likely be >> taking in the next few months. >> >> Don >> >> [1] http://www.source-code.biz/MiniTemplator/ >> [2] https://jsr311.dev.java.net/ >> [3] https://jersey.dev.java.net/ >> >> On Fri, Aug 22, 2008 at 4:31 PM, Frans Thamura <[EMAIL PROTECTED]> wrote: >> > hi all >> > >> > is it possible that S2 become part of JCP? >> > >> > java server action framework >> > >> > right now only component framework there >> > >> > any idea? >> > >> > >> > >> > -- >> > -- >> > Frans Thamura >> > Meruvian Foundation >> > >> > Mobile: +62 855 7888 699 >> > Linkedin: http://www.linkedin.com/in/fthamura >> > >> > Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... >> > URL: >> http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
