Does Struts really need two frameworks? (long)

[Dakota Jack]

Finally!

On 6/21/06, Ted Husted <ted.husted@...> wrote:

>
> On 6/21/06, Craig McClanahan <craigmcc@...> wrote:
> > If that means a (hopefully amicable) divorce, then so be it.
>
> If that's what the people working on Shale want, I doubt that the PMC
> would oppose a change of venue.
>
> If that is the case, then the next question would be whether Shale
> would be a better fit as a top-level ASF project, a subproject of
> MyFaces, or somewhere else entirely?
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

[Dakota Jack]

You cannot marry a pig and a fox, Don.  Let's get honest.  The only thing
that is ever going to satisfy Craig is to get the Struts name for JSF,
period.  Let him go ahead and try to make it on his own.  That won't work
and its failure will keep JSF from continuing its trampy attempt to
integrate with every Tom, Dick and Harry in town.

On 6/21/06, Don Brown <mrdon@...> 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 <mrdon@...> 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]
> >>
> http://www.oreillynet.com/onjava/blog/2006/06/isnt_rails_supposed_to_change.html
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@...
> >> For additional commands, e-mail: dev-help@...
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

[Dakota Jack]

The obvious truth is so easy to state.  Thanks, Tim.

On 6/21/06, Tim O'Brien <tobrien-asf@...> wrote:

>
> ...we're dealing with the ramifications of dismantling Jakarta from years
> ago.    I actually think that this situation would have never arose if
> Struts and Shale were two sibling subprojects in a larger Jakarta project.
> But, the Board spoke years ago, and umbrella projects were broken up
> because
> of oversight concens.
>
> This highly dormant non-member votes TLP for Shale.  This isn't meant as a
> slight towards Craig, rather I think that separating Shale into separate
> entity will help clarify the message of both Shale and SAF2.   Otherwise
> every Shale page on the site is like an if/else clause  "Use SAF2 if you
> like actions, but use shale if you...".   I take a look at the
> db.apache.orgTLP, and I don't wish that fate upon Shale.
>
> Shale should be a TLP, the Shale site should be self-hosting.   Struts is
> a
> TLP, the Struts site should be self-hosting.  There is obviously a good
> deal
> of exchange, but the frameworks "compete" (not my words).
>
>
>
> On 6/21/06, Ted Husted <ted.husted@...> wrote:
> >
> > On 6/21/06, Craig McClanahan <craigmcc@...> wrote:
> > > If that means a (hopefully amicable) divorce, then so be it.
> >
> > If that's what the people working on Shale want, I doubt that the PMC
> > would oppose a change of venue.
> >
> > If that is the case, then the next question would be whether Shale
> > would be a better fit as a top-level ASF project, a subproject of
> > MyFaces, or somewhere else entirely?
> >
> > -Ted.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>
>

--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

[Dakota Jack]

This is so odd.  You begin by recognizing the problem and trying to hide
it.  Now you deny the problem and want to continue it in spades.  Everyone
who knows anything about frameworks sees that these two frameworks are
inherently incompatible.  They have been from the start.  That is the
problem.  Had Craig not had a career dependent presently on the success of
JSF and also the pull at Struts, this mess would never have happened.

On 6/21/06, Don Brown <mrdon@...> wrote:

>
> Tim O'Brien wrote:
> > There is obviously a good  deal
> > of exchange, but the frameworks "compete" (not my words).
>
> While this may be true politically, from a code perspective, I completely
> disagree.  Just about every feature of Shale, AFAIK can easily be used
> with
> Action 2: Spring integration, clay, message bundles, basically anything
> that
> doesn't use an alternative NavigationHandler or Lifecycle.  I think Shale
> is a
> great project and plan to use it where I can in Action 2 JSF examples as
> it
> really makes JSF easier.  I think JSF is a very legitimate view option for
> Action 2 and Shale fills in JSF's gaps quite nicely.
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

[Dakota Jack]

Thanks, Ted.  Well said!

On 6/21/06, Ted Husted <ted.husted@...> wrote:

>
> On 6/21/06, Don Brown <mrdon@...> wrote:
> > I put this proposal out to help bring us together,
> > not precipitate a "divorce" :)
>
> We're not "divorcing" Tiles. Neither did we "divorce" any of the
> components that now live in the commons. We believed each of these
> codebase could attract a larger community on their own.  We didn't
> abandon these components, we still use them. And, no matter where it
> lives, now it looks like we can  still use Shale and other JSF
> components with SAF2. We can give away the cake and eat it too.
>
> As a PMC member, I'm concerned that, after all this time, Shale has
> still not had a GA release. We are all busy professionals, and we need
> a large community to push a release out the door. Shale has attracted
> a hard-working community, but it still has not attracted a large
> community.
>
> The question should be what is best for the Shale community?  Where
> will  the people working on Shale going to be the most productive?
> Where will they get the most help from other developers and users?
>
> At one time, the answer was here at Struts. But, 18 months later,
> maybe the answer has changed. Maybe the best thing for Shale would be
> to become a TLP, or a MyFaces subproject. I don't know myself. It's up
> to them that are doing the work.
>
> If the people working on Shale still think that this is the still the
> best location, then they have my support. But, I do think it is
> healthy to ask the question.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

[Dakota Jack]

The "Front Controller" is not really a controller.  It is a child's tool for
people who are challenged by OOP and need tool help.

On 6/21/06, Craig McClanahan <craigmcc@...> wrote:

>
> Comments interspersed.
>
> On 6/21/06, Don Brown <mrdon@...> wrote:
> >
> > Craig, thanks for your honesty and candor.  I know this is a delicate
> > topic, and I appreciate you approaching the topic openly.
>
>
> LIkewise ... I may have sounded a bit grumpy in my response, but I don't
> ascribe any malicious intent to your proposal.
>
> 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.
>
>
> In principle, that should work already for some things like
> ViewController,
> (but, if I read the current navigation handler right, you're not
> delegating
> so the "dialog" facility of Shale will not operate correctly at the
> moment).  Proof is in the pudding of course, by actually writing such a
> sample app.
>
>   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.
>
>
> Two separate thoughts on this:
>
> * Technically, having an Action2 type handler for these things is
> certainly
>   feasible, but not required.  Shale Remoting does the same sorts of
> things
>   for resource access, and supports dynamically mapping dynamic requests
>   to an arbitrary method on a managed bean (i.e. it gets instantiated on
> demand
>   and dependency injected), using standard JSF facilities, already.  And
> it
>   takes zero configuration if you like the default mapping algorithm.
> (Adding
>   xwork interceptor chains around the call to the dynamic handler methods
> will
>   be an easy add-on to this, for those who like that approach to providing
>   services to the handler.)
>
> * Philosophically, a framework built around JSF should encourage the
> developer
>   to use facilities that are already there, so he or she will not need to
> learn
>   new concepts.  That's why Shale does things like using method
>   binding expressions to configure actions in the dialog subsystem ...
> binding
>   an asynchronous callback is done exactly the same as binding a submit
>   button to an action method (execute() in action framework terminology).
>   Nothing new to learn.  Leverages the managed beans facility exactly the
>   same way.  Easily usable by a JSF component itself that wants to
> encapsulate
>   AJAX behavior or by client side JavaScript provided by the application.
>
>   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.
>
>
> There is a lot of space for implementing common frameworks we can share
> for
> doing things like validation -- for example, at JavaOne we talked a bit
> about a "Commons Validator 2.0" that could derive validation rules from
> annotations.  But, at the end of the day, you still need different
> mechanisms to embed the particular annotations into the UI toolkit you're
> using (the UI tags in SAF, or the component tags in JSF).
>
> For navigation, "you'd use Action 2 navigation rather than navigation
> handler" means that you're giving up on the tools around for JSF
> navigation,
> and forcing a beginner that is reading a JSF book to ignore that chapter
> and
> learn something different.  We'll want to look at how the existing SAF2
> navigation handler can delegate for scenarios where the developer wants to
> use JSF navigation for some namespaces.
>
> It's definitely possible to merge Action 2 and JSF in an application --
> you've already done that.  That's a tremendous benefit for the migration
> use
> cases, or those that just want to sprinkle some components without
> migrating.  For a new application, though, I don't care for the result,
> because it adds complexity (over pure JSF based solutions), and requires
> deveopers to deal with additional concepts and configuration files,
> without
> enough  corresonding benefits to make it worth it (IMHO, of course).
>
> 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" :)
>
>
> Doesn't it really come down to which front controller you choose as the
> primary foundation of your architecture?
>
> Nearly every existing framework that has added JSF integration has kept
> their original basic architecture, and thought of JSF primarily as a
> library
> of UI widgets.  Shale (and Seam) take a different viewpoint -- utilize the
> front controller built in to JSF instead, and decorate around the edges to
> add features and ease of use.  If you take that approach, you discover a
> very capable framework, usable for server generated markup or AJAX
> callbacks
> or any other sort of HTTP request, with basic IoC-ish bean instantiation
> and
> dependency injection built in, along with an expression language that can
> be
> used to bind components to model data, but can also be used
> programmatically
> by an application framework itself.
>
> Personally, I want to get out of the front controller business :-), and
> leave that problem to the MyFaces and RI teams to compete on quality and
> features.  I'd rather add value by leveraging concepts that a JSF-oriented
> developer already has to know about, rather than adding abstraction layers
> so I can be agnostic about the front controller that is under the covers.
>
> Don
>
>
> Craig
>
>

--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

[Dakota Jack]

The problem is that there is no common ground.  Pretence is great, but not
really effective.  It will bit you in the butt later.

On 6/21/06, Don Brown <mrdon@...> wrote:

>
> You make a lot of good points, and a strong argument for rallying around
> the JSF
> flag.  To this end, Shale is a great idea and provides a nice realization
> of
> this approach.  Undoubtedly, there are many developers who think similarly
> and
> may not ever be interested in the Action 2 controller, and Shale should
> always
> be there to make their lives easier.
>
> Others, however, may find uses for an Action 2 controller in a pure JSF
> application:
>   * AJAX services that return JSON/XML - The Action 2 controller separates
> the
> rendering of the result from the method, so the method can return objects,
> and
> the configurable Result can handle the JSON or XML serialization.
>   * Public high-load browsing pages - The Action 2 controller provides
> minimal
> overhead and the possibly of completely stateless, sessionless
> operation.  Web
> designers can use Velocity, JSP, Freemarker, etc to create the pages.
>   * Generated images - An application may have need to create charts,
> graphs, or
> other generated images.  Action 2 provides a framework to separate the
> logic
> from the rendering, and even has built-in support for JFreeChart.
>   * PDF reports - Likewise, there may be a need for generated PDF reports.
> Action 2 also has support for Jasper Reports, although any reporting
> engine can
> be easily plugged in.
>   * Alternate view technologies - A section of the team may already be
> familiar
> with Velocity, Freemarker, or even XSLT and want to use that for the view.
>
> Finally, the Action 2 dispatcher is actually a ServletFilter, so it is
> very easy
> to have both controllers work side-by-side, even in the same request.
>
> Not every JSF application will have a need for Action 2, but putting them
> together in the same Struts 2.0 release provides a single place for the
> developer to learn about their options and see what fits best where.
>
> > * Philosophically, a framework built around JSF should encourage the
> > developer
> >  to use facilities that are already there, so he or she will not need to
> > learn
> >  new concepts.
>
> I agree common standards are important, and that is why we are looking to
> see
> how we can leverage standards like EL and JSF where we can.  However,
> there are
> cases where the standard may be lacking and it is necessary to use a
> replacement
> (Freemarker/Velocity, OGNL, Spring, etc).
>
> > For navigation, "you'd use Action 2 navigation rather than navigation
> > handler" means that you're giving up on the tools around for JSF
> > navigation,
> > and forcing a beginner that is reading a JSF book to ignore that chapter
> > and learn something different.  We'll want to look at how the existing
> SAF2
> > navigation handler can delegate for scenarios where the developer wants
> to
> > use JSF navigation for some namespaces.
>
> True, but so does Clay, Facelets, and Shale dialogs change a "pure" JSF
> app, but
> as long as it is optional, it shouldn't be a big deal.  That said, I
> really like
> your idea for delegation and am very open to putting that into Action 2.
>
> > It's definitely possible to merge Action 2 and JSF in an application --
> > you've already done that.  That's a tremendous benefit for the migration
> > use
> > cases, or those that just want to sprinkle some components without
> > migrating.  For a new application, though, I don't care for the result,
> > because it adds complexity (over pure JSF based solutions), and requires
> > deveopers to deal with additional concepts and configuration files,
> without
> > enough  corresonding benefits to make it worth it (IMHO, of course).
>
> But you really can't have it both ways - either you replace existing
> functionality or you have duplication.  I think this is a problem even for
> Shale
> - duplicating resource loading, navigation, view templating, etc.
>
> > Doesn't it really come down to which front controller you choose as the
> > primary foundation of your architecture?
>
> Yes, but in making that decision, all things equal, you should choose the
> more
> generic/flexible one in front.  Still, I hold to the argument that the the
> decision is invalid as there is a middle ground in using both.
>
> > Personally, I want to get out of the front controller business :-), and
> > leave that problem to the MyFaces and RI teams to compete on quality and
> > features.  I'd rather add value by leveraging concepts that a
> JSF-oriented
> > developer already has to know about, rather than adding abstraction
> layers
> > so I can be agnostic about the front controller that is under the
> covers.
>
> And this is why Shale needs to continue, and I'd argue, continue to exist
> as
> part of the larger Struts community, and a step further, under a larger
> "Struts
> 2.0" product.  I think despite providing multiple alternatives and
> solutions,
> there is a common narrative we can weave to create a unified Struts
> project.
>
> Don
>
> >
> > Don
> >
> >
> > Craig
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

[Dakota Jack]

The success of Spring is not that "people like modularity".

On 6/21/06, Frank W. Zammetti <fzlists@...> wrote:

>
> Ted Husted wrote:
> > So, in addition to including the Action 1.3 JARs in the SAF 2.0
> > release, essentially, you are suggesting that we also include the
> > Shale 1.x JARs in the same distribution, so that anyone obtaining SAF2
> > can use Action 1, Action 2, and/or Shale 1?
>
> Even though Don hasn't answered yet, I have to say I agree with Joe, and
> I hope that wasn't the idea... if we have learned anything from the
> success of Spring, it should be that people like modularity.  Making
> sure that Action 1.3, SAF2 and Shale 1.x can be used together as desired
> is one thing, bundling them all together is another.  I don't think that
> will make things easier or less confusing, on the contrary, I can't
> imagine it would do anything but make people scratch their heads even
> more.
>
> > -Ted.
>
> Frank
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

[Dakota Jack]

It would be impossible to pull off.  Since Struts and JSF are inherently
incompatible, there would be a my way or I will run away from home from
Craig and an unwillingness of the Struts community to quit a true controller
based framework.  There is no way to make this marriage work.

On 6/21/06, Patrick Lightbody <forum-struts-dev@...> wrote:

>
> My quick thoughts: I think realistically either of the following two
> outcomes are positive developments for everyone:
>
> 1) We move in the direction of "Struts 2.0", which houses all SAF2 and
> Shale and get back for it being OK for folks to say, "I use Struts". We've
> all said we want to work together closer, but it's just talk until we take
> action to do so. This strategy, as proposed by Don in this thread, would be
> the first step in taking action.
>
> 2) Shale becomes a TLP. We continue to share code and ideas where it makes
> sense, but that is entirely optional. This is effectively what we have now,
> except that it would be formalized.
>
> I would prefer option #1, but I know it could be hard to pull off. Either
> way, both are good routes to go down and would be healthy for the community.
>
> Patrick
> ---------------------------------------------------------------------
> Posted via Jive Forums
>
> http://forums.opensymphony.com/thread.jspa?threadID=34915&messageID=68478#68478
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

[Dakota Jack]

What is the problem?  Who caused it?  Bingo!  Eureka?

On 6/21/06, Don Brown <mrdon@...> wrote:

>
> Paul Benedict wrote:
> > I don't see the point in bundling Shale into a "Struts 2.0"
> distribution. No
> > offense to anyone who develops Shale, but when we have packages called
> > "action2", it makes it pretty clear Shale is not Struts 2.0 -- only the
> action
> > framework. Separate frameworks, imo, get different names and
> distributions. I am
> > not offended Shale is within the Struts community, but I do not see it
> as the
> > torch bearer to the name Struts -- I do see that with the AF, which
> historically
> > holds the name.
>
> Again, Struts Action and Struts Shale would both retain their separate
> projects,
> codebases, and release cycles.  Struts 2.0 is about building something on
> top of
> our Struts efforts to create a unified front to users.  Users don't care
> about
> all the little projects, subprojects, and libraries we have; I think they
> just
> want something to help them build webapps - they want Struts 2.0.  And as
> a
> committer, PMC member and Struts user, I want it too.
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

[Gary VanMatre]

>From: "Dakota Jack" <dakota.jack@...>
>
> These are not "camps" of a framework but competing frameworks. That is the
> bottom line. Struts is dying and you guys, Gary, are killing it. Why not
> man up and get your own space and try to survive on your own?
>

I'm not opposed to Shale moving out if the majority is in favor of webwork and apache "Struts" is really just about "a" framework.   I'm an invited guest and my motivations are much simpler than what you are implying.  

Gary


 

> On 6/21/06, Gary VanMatre wrote:
> >
> > >From: "Ted Husted"
> > >
> > > On 6/21/06, Don Brown wrote:
> > > > Again, Struts Action and Struts Shale would both retain their separate
> > > projects,
> > > > codebases, and release cycles. Struts 2.0 is about building something
> > on top
> > > of
> > > > our Struts efforts to create a unified front to users. Users don't
> > care about
> > > > all the little projects, subprojects, and libraries we have; I think
> > they just
> > > > want something to help them build webapps - they want Struts 2.0. And
> > as a
> > > > committer, PMC member and Struts user, I want it too.
> > >
> > > Wearing my PMC hat, I'd be surprised if that approach would well serve
> > > the Shale community. You can dress it up anyway you want, but in the
> > > end, this approach will have the effect of demoting Shale to an
> > > appendage of SAF, rather than a framework in its own right.
> > >
> > > We like to chatter about what's best for Struts, or what Struts is,
> > > but I think the key question is what's Shale, and what's best for
> > > Shale? I remain concerned that, after two years on a greenfield, there
> > > has not been a GA release of Shale. I have to wonder if keeping Shale
> > > here is stunting the community's growth.
> > >
> > > We've heard from Craig, but in order to make any kind of decision, I'd
> > > have to know how the other people working on Shale feel.
> > >
> >
> > I think we could use some more Shale recruiters but I don't necessarily
> > think
> > that is because of lacking community support. I can think of several
> > people
> > that I feel have been worthy contributors but we have been very
> > conservative.
> > The SAF camp has recently been very active in recruiting anyone showing
> > interest.
> >
> > I don't have a strong opinion either way. I remember someone saying that
> > they have
> > precious little time and I sympathize. Making this happen is really a team
> > effort and
> > you have to pick your battles. Even though I have not made the time to
> > evaluate the
> > latest in the action camp, I truly enjoy the exchange of ideas.
> >
> > If we continue to share a single community, I don't think that it is wise
> > to force both
> > camps into a single shoe box. On occasion we might want to get funky
> > mixing styles
> > but most like to play it safe, after all, it's about the right context.
> >
> > Gary
> >
> > > -Ted.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@...
> > > For additional commands, e-mail: dev-help@...
> > >
> >
>
>
>
> --
> "You can lead a horse to water but you cannot make it float on its back."
> ~Dakota Jack~

[Greg Reddin-3]

On Jun 21, 2006, at 8:31 PM, Ted Husted wrote:

> We like to chatter about what's best for Struts, or what Struts is,
> but I think the key question is what's Shale, and what's best for
> Shale? I remain concerned that, after two years on a greenfield, there
> has not been a GA release of Shale. I have to wonder if keeping Shale
> here is st