On Fri, Aug 22, 2008 at 8:36 PM, Don Brown <[EMAIL PROTECTED]> wrote:
> Personally, I don't think Struts 2 has a strong enough API, ok, I > _know_ Struts 2 doesn't have a strong enough API to be turned into a > JSR, currently anyway. Bob did some work trying to define such an > API, and is probably 80% of the way there, but I wonder if the > technology has moved on a bit since then... > > For fun in a side project, I'm going back to pure Servlets and a > simple template language [1] to better understand what a web framework > really needs to provide. As I see the options now you have: > * Rails/Merb/Grails - rapid development, scripting language base, > solid best of breed stack (for Grails anyway) under the covers. On > the other hand, using any of these to write a hello world war is > something like 25 megabytes and a ton of dependencies. That is fine > for shops that need to get something up quickly and are starting from > scratch, but not for others. > * JSF/Wicket/Tapestry - component development for swing/drag-and-drop > folks, ability to wrap up complex bits into new components, usually > nice tool support. On the other hand, their apps tend to not be > RESTful and take you quite a ways from HTTP. Also, they usually > involve a lot of server-side state management which can impact > scalability and they sometimes rely on a Javascript to really work. > Finally, each tends to really favor their one template language by > design, limiting options down the road. > * Struts/Stripes/Spring MVC - lightweight MVC frameworks with minimal > dependencies, with a specific focus on the presentation tier. Easy > access to HTTP features, not much to learn, can fit easily into most > application stacks, and tend to be very RESTful. These frameworks > tend to be fast, impose little requirements on the session, and work > with most template engines. 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. -- 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] > >
