struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <>
Subject Re: Does Struts really need two frameworks? (long)
Date Wed, 21 Jun 2006 16:19:53 GMT
One other point of clarification I forgot - this proposal would have no effect 
on the Struts Shale project from a code or release perspective.  The Struts 
Shale project would continue, put out its releases, and continue to support JSF 

I'm really only suggesting we wrap it all together as an official "Struts" 
release similar to our "Struts Library" releases of old, as an aid for Struts 
users who want a single release to download and learn.  This meta release would 
have unified documentation, example apps, and tutorials, but all the code would 
be in the three Struts subprojects: Shale, Action 2, and Action Tags.


Don Brown wrote:
> Craig, thanks for your honesty and candor.  I know this is a delicate 
> topic, and I appreciate you approaching the topic openly.
> A couple of clarifications:
>  1. I'm not proposing Shale _ever_ depend on Action 2, only that they 
> should work well together.  In fact, I mean to start including Shale in 
> Action 2's web examples.
>  2. In a "pure JSF" environment, don't you think there is value in using 
> an Action 2 controller to handle things like JSON/XML remote services?  
> I'm finding more and more my Struts Actions return JSON rather than 
> HTML.  This is how I see us working together even if you don't use 
> Action 2's JSF support.
>  3. Overlap areas like navigation, validation, messages, etc., are only 
> waiting on attention to be resolved.  When using the Action 2 
> navigation, it is my intention that the default configuration removes 
> overlap as much as possible.  You'd use Action 2 navigation rather than 
> the NavigationHandler.  Validations could be defined in the page or 
> could automatically be created from existing Action 2 validations (XML 
> or annotations), similarly to how Seam creates validations from 
> annotations.  Messages integration is easily resolved by creating a 
> backing bean that provides messages using Action 2 apis.  I fully 
> believe it is possible to merge Action 2 and JSF into a web application 
> in a seamless manner.
> I guess what I'm saying is you could view this "overlap" in a negative 
> or positive light.  I think the Struts project should put forth a 
> "preferred" approach, used in our quickstarts and tutorials.  However, 
> that doesn't mean that we should force developers into our way of 
> thinking.  Having options isn't necessarily bad.
> At this point, I really don't see a valid either/or framework approach 
> debate:
>  - If your application needs to be built by tool-dependent programmers, 
> pure JSF is definitely the way to go.
>  - If you prefer the pure JSF approach for other reasons, use a pure JSF 
> framework, but perhaps use Action 2 to organize and deliver JSON/XML 
> services.
>  - If your application has a lot of Struts developers or stateless pages 
> that need pure speed, but in sections you want to use fancy JSF 
> components, use Action 2 as the controller and sprinkle in JSF where 
> needed.
>  - If you like Action-based approaches and don't need/like JSF 
> components, just use Action 2.
> I hope we can agree that each of the above situations and solutions is 
> valid, and make that our common ground.  You may prefer the first 
> couple, others the latter two.  As a Struts project, we need to be of 
> one mind in at least some things, and it is my hope Action 2's recent 
> JSF integration attempts can help get us there.  I put this proposal out 
> to help bring us together, not precipitate a "divorce" :)
> Don
> Craig McClanahan wrote:
>> The short answer is that no, as long as I have any say in it, Shale 
>> will not
>> morph to be dependent on Action2.  SAF2 is too heavyweight and too
>> complexfor my tastes (see below for more about that remark), besdes 
>> the fact
>> that it implements a lot of stuff that is redundant to what is already 
>> part
>> of JSF (and therefore Shale) that -- from the perspective of a new
>> application deveoper -- just complicates the picture instead of 
>> simplifying
>> it.
>> Don't get me wrong ... SAF2 is a very elegant evolution of the
>> action-oriented controller paradigm.  It's the paradigm that I have a
>> problem with.
>> The complete longer answer will need to wait until I finish my 
>> analysis of
>> what Don did (but thanks for addressing WW-1357 right away!) to 
>> improve the
>> support for JSF components in SAF2.  But the bottom line is that, in 
>> 2006, I
>> have philosophical differences with action oriented frameworks (in the 
>> sense
>> of what we see available today) as the right long term answer to 
>> designing
>> new Java based web applications -- Struts or WebWork or whatever.  It's
>> wonderful that you are looking out for the migration use case, where 
>> people
>> need to add a few JSF components to their existing Struts or WebWork 
>> based
>> apps.  No matter what happens, I can be comforted by the fact that people
>> wanting to add a bit of JSF component wizardry to their existing apps 
>> will
>> have that option.
>> But the end result of an SAF2 + JSF based application is pretty much the
>> same, from an architectural viewpoint, as the result of a Struts 1.x +
>> Struts-Faces integration library + JSF based application.  You end up 
>> using
>> only part of JSF (the UI components part ... valuable, yes, but not the
>> whole story).  Worse, though, you end up with this wierd mismash of a 
>> front
>> controller in front of a front controller (mashed teogether in the
>> interceptor chain in the SAF2 implementation, but the same conceptually).
>> Leading to continual decisions during the maintenance phase of a 
>> development
>> project ... do I add a new page via action-framework navigation, or JSF
>> navigation?  Do I use the action framework's validation scheme, or 
>> JSFs?  Am
>> I forced to depend on Spring or whatever for dynamically created beans 
>> with
>> dependency injection, or can I rely on the fact that JSF already 
>> provides a
>> basic facility for this?  Red Flags time!
>> Indeed, one could make the same argument Don makes about 
>> consolidation, but
>> in favor of adopting JSF as the fundantal controller architecture, and
>> providing a full-up JSF implementation (probably based on MyFaces) 
>> that also
>> incorporated XWork interceptors on each lifecycle phase (see SHALE-106 
>> and
>> SHALE-136).  At least you could test such a thing for compliance with the
>> JSF spec, and not have to hope that the folks that are utilizing some 
>> of the
>> more critical JSF extension points are doing so in a manner that is 
>> going to
>> be compatible with "pure JSF" component libraries and frameworks.
>> To me, it does not make sense for a framework to say "I adopt JSF" but 
>> then
>> have *redundant* implementations of things like validation and navigation
>> and depdency injection and expression evaluation and ....  This is 
>> fine for
>> a migration story, but for new development it needlessly complicates the
>> architecture of the resulting aplications. JSF already supports 
>> navigation
>> (pluggable, if you want something completely different).  Why should I be
>> forced into SAF2 Results?  JSF already supports a validation framework
>> (easily extensible to client side validation, see Shale's feature in this
>> respect).  Why should I limit myself to what SAF2 offers?  JSF has 
>> managed
>> beans for basic dependency injection (including the abiltity to inject 
>> beans
>> into a particular scope, which Spring is only now supporting in 2.x).
>> Why should I go back to a single execute method (plus prepare() if you
>> implement Preparable) as the only application events an action ever hears
>> about, versus the four supported by Shale's ViewController?  Why 
>> should I be
>> required (or encouraged) to use Spring even if I don't need all the fancy
>> stuff like constructor injection that Spring provides (which, by the way
>> "works fine lasts a long time" with pure JSF already)?  To say nothing of
>> the fact that not using managed beans means you are passing on the 
>> resource
>> injection facilities already available in Java EE 5.  To say even more
>> nothing about the future ... keep an eye on things like JSR 299 if you 
>> want
>> to see where the "mainstream" market is going ( i.e. not necessarily what
>> the geeks like, but where the market opportunity for consultants is 
>> going to
>> be the best :-).
>> Personally, I can look back with a lot of pride at the longevity of the
>> MVC-oriented concepts that Struts 1.x brought to the web application 
>> space.
>> Sic years in Internet time is FOREVER!  But, for me, it's time to move 
>> on.
>> I care passionately about a migration path for existing Struts-based 
>> apps,
>> and the current SAF2 approach is acceptable for that (although it's
>> certainly feasible to do better on "migrate to JSF' than "migrate to 
>> SAF2"
>> for current Struts 1.x users).  You won't hear any whining about the
>> fundamentals from me of SAF2 -- although I reserve the right to 
>> comment on
>> the details :-)
>> But, for new developers, I prefer to think of action-oriented 
>> frameworks as
>> "been there, done that".  The understanding of O-O concepts, and the
>> willingness to code things in configuration files (I *hope* you guys are
>> thinking about annotations for things like Preparable :-) you need to 
>> really
>> leverage all the cool stuff that SAF2 includes is far too limiting for my
>> vision of what Java as a platform needs to do in the future.  I want to
>> focus on attracting a much larger audience of developers who are *not* 
>> O-O
>> professionals, whose idea of "code reuse" is cut-n-paste, and who might
>> actually prefer to use tools (SAF2's fundamental architecture is 
>> pretty much
>> untoolable, even if someone were motivated to spend the effort to build
>> tooling around it).  For the O-O bigots around this mailing list, I 
>> can take
>> comfort in the fact that the audience I'm interested in is *many 
>> times* the
>> size of the audience that will actually appreciate the technical 
>> elegance in
>> SAF2.
>> Or, if you want it all in one sentence:  for new developers, I would much
>> prefer to compete with SAF2 than to cooperate with it.
>> If that means a (hopefully amicable) divorce, then so be it.  SAF2 is 
>> a much
>> better (technical) approach to the problems that Struts 1.x targeted, but
>> the world has moved beyond those problems.  I'm no longer interested in
>> playing on that particular playground.
>> Craig McClanahan
>> On 6/20/06, Don Brown <> wrote:
>>> As Shale and Action zero in on their first GA release, I don't think 
>>> it is
>>> too
>>> late to ask the question, "Does Struts really need two frameworks?"  We
>>> have
>>> been putting out the message, "two frameworks, one community", for 
>>> almost
>>> a year
>>> now, but I still sense a lot of confusion and even rejection from the
>>> Struts
>>> community.  The problem is for our whole history, Struts was a single
>>> framework,
>>> what you went to if you wanted to structure your web application 
>>> according
>>> to
>>> Model2 principles.  Our attempts to turn Struts into an umbrella 
>>> project,
>>> I
>>> feel, have failed.
>>> Struts Action 2 is seen, by some, as a simple rebranding of WebWork 
>>> 2, and
>>> to be
>>> honest, it really is at this stage.  Struts Shale is seen as 
>>> non-sequitur,
>>> milking the Struts brand name.  While these opinions are most extremely
>>> expressed by our more radical members, they are also held to some degree
>>> by some
>>> very smart, sensible people [1].
>>> From a Struts committer perspective, Wendy made a good point to me the
>>> other
>>> day saying that Struts lacks the single purpose or vision of most Open
>>> Source
>>> projects.  Despite our recent attempts to find common ground, Shale and
>>> Action
>>> are still positioned as competing frameworks with no overlap.  This
>>> division
>>> leads to conflicts that suck the joy out of Open Source development.
>>> Recently, Struts Action 2 unified the programming models of action-based
>>> and
>>> component-based development by allowing the developer to adopt an
>>> action-based
>>> approach for an application, yet use JSF components and abilities where
>>> needed.
>>>   We have always said the desired end state would be to return Struts 
>>> into
>>> a
>>> unified framework, and I think we should jump on this chance now.
>>> I propose Struts return to its roots as a unified framework through
>>> building on
>>>   three libraries to make JSF and pure Servlet/JSP development
>>> easier.  Namely,
>>> I propose the Struts project to be the following subprojects, each with
>>> their
>>> own release cycle:
>>>   - Framework: Struts 2
>>>   - Libraries: Struts Action, Shale and Struts Tags
>>> Struts would be the single framework the world would see.  It would
>>> contain
>>> support for Action-based, JSF-based, and hybrid applications.  Its
>>> documentation
>>> would promote the Struts Action controller as the preferred entry point,
>>> even if
>>> only to be used for AJAX services.  Its JSF library, Struts Shale,
>>> however,
>>> could be used with a regular FacesServlet.  JSF components and Struts 
>>> Tags
>>> would
>>> be equals when describing how to tackle the View of an application.
>>> Struts Action would be the core library driving Struts 2, replace Struts
>>> 1.x.
>>> This library would be everything now known as Struts Action 2, but 
>>> without
>>> the
>>> UI components.  We would aim for a solid Action-based library 
>>> independent
>>> of the
>>> view, much like Action 1.x.  When we talked about what an Action JSR 
>>> would
>>> look
>>> like, this would be it.
>>> Struts Shale would be repositioned as a library, which I think is a 
>>> better
>>> fit.
>>>   A framework to me is a comprehensive, one-stop-shop solution to create
>>> an
>>> application.  A library is a collection of independent features that can
>>> be used
>>> in piecemeal.  Therefore, I think a library is a better definition for
>>> Shale's
>>> collection of JSF extensions.  While Struts Action would definitely
>>> support
>>> Shale, it would continue to be able to be used with pure JSF 
>>> applications.
>>> Struts Tags would be the WebWork UI components, a library of re-usable,
>>> stateless tags that can be used in Velocity, Freemarker, or JSP.  They
>>> would
>>> include current and future AJAX tags.  These tags would most likely 
>>> remain
>>> tied
>>> to Struts Action 2, but not necessarily.
>>> How would this benefit Struts Action? By splitting of the tags, we can
>>> focus on
>>> the core project and get it out the door quicker.  By publicizing our 
>>> JSF
>>> and
>>> Shale integration, we would open our framework up to a broader audience.
>>> How would this benefit Struts Shale? Shale would also be opened up to a
>>> broader,
>>> Action-based audience and wouldn't be seen as a competitor to Struts
>>> Action.  It
>>> wouldn't lose its autonomy or pure JSF support.  It would gain developer
>>> support
>>> as more Action-based apps would start to use JSF and need Shale.
>>> How would this benefit Struts Tags? The tags could evolve quicker with
>>> faster
>>> releases due to less code.  They would be free to add new marginal
>>> features
>>> without worrying about bloating Struts.  This project would be analogous
>>> to
>>> MyFaces Tomahawk as a library of components.
>>> How would this benefit the Struts community? Finally, Struts returns to
>>> its
>>> roots as a single framework.  While pieces of it may be usable 
>>> outside the
>>> Action-based controller like Shale, it becomes the single place you 
>>> go to
>>> solve
>>> your application development needs.  The documentation would be unified
>>> and the
>>> supporting committer community in step.  If you wanted the whole
>>> framework, you
>>> download Struts.  If you just want one of the libraries, they are
>>> available ala
>>> carte as well.
>>> This proposed change is primarily one of message and vision, and should
>>> have
>>> minimal impact on current development activity.  With the next 
>>> generation
>>> of
>>> books and conferences in the works, I think it is important to develop a
>>> clear
>>> message to the Struts community and minimize any confusion.
>>> The bottom line is we want Struts to be the place to go to make web
>>> development
>>> easier, faster, with less hassles.  I think this proposal provides the
>>> vision to
>>> make that happen.
>>> Don
>>> [1] 

>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message