I've also been thinking along these lines, starting about a year back when there was discussions around the convention plug-in. Although it was motivated more on a clean annotation implementation - as there seemed to be a good synergy between the JSR-311 annotations and what s2 could leverage (as opposed to defining new annotations).

/Ian

Don Brown 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.

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]

Reply via email to