Does Struts really need two frameworks? (long)

[Don Brown-2]

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@...

[Michael Jouravlev]

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?"

I bet DJ and JR are laughing their asses off.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank W. Zammetti]

Just last week I was talking to another senior architect at my company,
and he was asking me how a developer knows what they should get when
they go to the Struts site?  He was asking me what "Struts" was at this
point.  It was more than just a navigation issue, he thought there was a
very confused message.  I agreed with him, and have for some time...
I've spoken on this in the past, but I hope I'm not counted as one of
"our more radical members"! :)

I personally came to grips with how things were a while ago, but it's
nice to see someone on the Struts team tackling the same issue.
Clearly, as evidenced by that conversation last week, it's still
definitely an issue that could use some discussion.

My one thought when reading your proposal Don is that I'm not sure what
answer I would have been giving him if things were the way you
describe... I'm not sure, to me anyway, that it really clarifies anything.

I'm also not sure I agree that Shale could be considered a library.
People tend to think of a library as something relatively lightweight,
and with all that Shale offers, I'm not sure I could ever consider it
that.  Your point about it being able to be used peace meal makes some
sense, but I'm not sure something ceases to be a framework just because
you can swap pieces in and out, or not use pieces at will.  To me, that
just makes it very flexible :)

I'm also concerned that building such a "hybrid", as you describe, would
lead to even more confusion, even though it's one framework.  I happen
to agree with you, and similarly have changed my thinking a bit, in
terms of frameworks being wider in scope than Struts historically has
been.  On the other hand, coming to something like Webwork is, I think,
more daunting than "classic" Struts precisely because there is so much
more to take in, and I think such a hybrid would only be that much more
daunting.  Struts has been the success it has been largely because it's
been pretty easy for people to pick up and go (we're only starting to
think otherwise with the advent of things like Rails, which makes it
even easier purportedly, but before that, Struts was pretty good!).

While I'm not sure about the details of your proposal (nor am I honestly
sure how to do any better), I do think it tries to address the root
problem: the Struts "umbrella" idea, from what I've heard talking to the
people I talk to, has lead to more confusion than anything else.  I
think it disregards a key historical point: that "Struts" meant a very
specific thing: a framework, for a long time.  That's what people know
it as.  I don't know if the umbrella idea was a good one or not, and
that probably doesn't matter any more anyway... I get the sense that the
message of that conceptual change didn't get translated very well to a
lot of people outside the Struts team, and that's where the confusion
comes from.

Just some initial thoughts anyway... your underlying principal is one I
can get behind, although I'm not sure yet if I quite like the
particulars :)  In any case, I'm glad it's apparently not a taboo
subject, as it sometimes seemed in the past.

Frank

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]
> 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@...
>
>
>
>

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@...
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Michael Jouravlev]

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.

Robert Cringely's Accidental Empires: Pages 293,294
  Microsoft began moving away from OS/2 in 1989 when it became
  clear that DOS wasn't going away, nor was it in Microsoft's
  interest for it to go away.  The best solution for Microsoft
  would be to put a new face of DOS, and that new face would
  be yet another version of Windows.  Windows 3.0 would include
  all that Microsoft had learned about graphical user interfaces
  from seven years of working on Macintosh applications.
  Windows 3.0 would also be aimed at ... 386 processors...
  would give users 90 percent of the features of OS/2...

Robert Cringely's Accidental Empires: Page 295
  [Gates] recognized, even if IBM didn't,
  that the market had grown to the point to where no one company
  could define and defend an operating system standard by itself.
  Without Microsoft's help, Gates thought IBM would fail. With
  IBM's help, which Gates viewed as meddling more than assistance,
  Microsoft might fail.  Time for a divorce.

Quotes pulled from comp.os.os2.advocacy, Oct 6 1992.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ted Husted-5]

Yes, it would be helpful to find a good way to make JSF easier to use
in a conventional Action-based application, much the same way we are
trying to make Ajax easier to use in SAF2.

Our first attempt (as a project) at JSF/Action integration was the
Struts JSF taglib. The promise here was to migrate a Struts JSP to
JSF, one page a time. It sounded good, but unfortunately, it didn't'
work out as well in practice.

Our second attempt is Shale. Since we couldn't find a way to integrate
JSF into an Action-based framework, we erased the whiteboard and
started over. While this approach seems to be working well for people
ready for a clean break, it is not creating a migration path for
Action-centric developers.

Our third attempt at integration is the recent work that tacks JSF
components onto SAF2. If this third attempt pans out in practice, and
works with extensions like Clay, then, sure, we might be able to
position Shale as the JSF extension to SAF2. Much like we're talking
about creating an Ajax extension based on DWR or Dojo.

As for making the UI tags an independant extension, a al Tiles, that
sounds good too. (Even better if we include the "value added" Ajax
support.) But I don't know if we want to hold back the SAF 2.0.0 to
make it happen. But, for phase 2, sure!

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Don Brown-2]

Ted Husted wrote:
> As for making the UI tags an independant extension, a al Tiles, that
> sounds good too. (Even better if we include the "value added" Ajax
> support.) But I don't know if we want to hold back the SAF 2.0.0 to
> make it happen. But, for phase 2, sure!
Actually, I'm thinking splitting off the tags would help us get SAF
2.0.0 out the door sooner.  A lot of our remaining tickets are for AJAX
tags, which would be in this new project.  As for the Tiles comparison,
that is exactly what I was going for.

And to be clear, the tags, at least for the near term, would stay
dependent on Struts Action 2.  The reason to split them off would be to
give them their own release cycle and make Struts Action 2 releases more
focused and quicker.  The tags have their own group of interested
committers, so I don't see a repeat of our last spinoff attempt. :)

Don

>
> -Ted.
>
> ---------------------------------------------------------------------
> 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@...

[Alexandru Popescu ☀]

Hi everybody!

I've read this thread a couple of times, because I was having a
somehow weird sentiment while doing it. Now, I think I have figured it
out :-). So, please bear with me for the short following paragraphs (I
am not a good writer yet):

1. even if I don't know too many details about Struts history, I
somehow agree with Don's opinion that changing it to be an umbrella
project may become confusing for the existing users, for new users and
for users that might consider migrating to newer approaches. But...

2.  this single package, solve-all idea, is something that RoR prooved
to be the wrong approach. I am playing now with RoR and I frankly
don't see anything in RoR over WebWork (really). But, what I am seeing
behind RoR is a very simple idea: drop it in and it will help you
build very quickly an web app (or at least some of them). And the
single-package-solves-all is exactly the opposite. People will not be
able to just drop in a couple of jars (for people knowing RoR, read it
a couple of gems) with their dependency managed directly and start
working on your app in a couple of seconds. It will be something like:
drop this in and now let's start and think: what other piece do I
need? Is it actions? Is it JSF? Is it X or Y? What dependencies should
I use for X over Y? And so, we are once again gonna fail the
simplicity that RoR proposed to web development (and IMO this is the
sole real contribution). Convention over configuration cannot work
with a big-solve-all package/framework. And this will leave the Java
web apps world for another period as a "zombie in the dark".
WebWork has tried to adapt to this new approach proposed by RoR. And
it was nice to see it. We may have a few more ideas to make it even
simpler in the near future. But this will not work with the
big-solve-all approach.

Indeed, this may look at the first glance as another, but opposite
radical view. It is only my opinion, as a guy being involved in the
Java world for 10 years and seeing everywhere people thriving to take
a decission. IMO another big-all-solve-all approach will not be able
to solve this problem, nor to simplify it in the future.

BR,

./alex
--
.w( the_mindstorm )p.


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

> Ted Husted wrote:
> > As for making the UI tags an independant extension, a al Tiles, that
> > sounds good too. (Even better if we include the "value added" Ajax
> > support.) But I don't know if we want to hold back the SAF 2.0.0 to
> > make it happen. But, for phase 2, sure!
> Actually, I'm thinking splitting off the tags would help us get SAF
> 2.0.0 out the door sooner.  A lot of our remaining tickets are for AJAX
> tags, which would be in this new project.  As for the Tiles comparison,
> that is exactly what I was going for.
>
> And to be clear, the tags, at least for the near term, would stay
> dependent on Struts Action 2.  The reason to split them off would be to
> give them their own release cycle and make Struts Action 2 releases more
> focused and quicker.  The tags have their own group of interested
> committers, so I don't see a repeat of our last spinoff attempt. :)
>
> Don
>
> >
> > -Ted.
> >
> > ---------------------------------------------------------------------
> > 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@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ian Roughley]

If the goal is to separate the life cycles or to share code, then I am
all for it.

But I don't think the end users perception is going to be any different
by this proposed change.  The question is still going to be "are we
going to use a JSF or action framework?"  Struts is not advocating a
preference (and I don't think it should) and I believe this is the
confusion for most people when making a choice.


/Ian


Don Brown wrote:

> Ted Husted wrote:
>> As for making the UI tags an independant extension, a al Tiles, that
>> sounds good too. (Even better if we include the "value added" Ajax
>> support.) But I don't know if we want to hold back the SAF 2.0.0 to
>> make it happen. But, for phase 2, sure!
> Actually, I'm thinking splitting off the tags would help us get SAF
> 2.0.0 out the door sooner.  A lot of our remaining tickets are for
> AJAX tags, which would be in this new project.  As for the Tiles
> comparison, that is exactly what I was going for.
>
> And to be clear, the tags, at least for the near term, would stay
> dependent on Struts Action 2.  The reason to split them off would be
> to give them their own release cycle and make Struts Action 2 releases
> more focused and quicker.  The tags have their own group of interested
> committers, so I don't see a repeat of our last spinoff attempt. :)
>
> Don
>
>>
>> -Ted.
>>
>> ---------------------------------------------------------------------
>> 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@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[craigmcc]

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@...
>
>

[Ted Husted-5]

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@...

[Don Brown-2]

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@...

[Don Brown-2]

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
applications.

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

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 <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@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Tim O'Brien-4]

...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@...
>
>

[Don Brown-2]

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@...

[Ted Husted-5]

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@...

[craigmcc]

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

[Don Brown-2]

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@...

[Ted Husted-5]

On 6/21/06, Don Brown <mrdon@...> wrote:
> 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.

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?

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Joe Germuska]

At 3:22 PM -0400 6/21/06, Ted Husted wrote:

>On 6/21/06, Don Brown <mrdon@...> wrote:
>>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.
>
>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?

I don't like including either Action 1.3 or Shale 1.x in the SAF 2.0 release.

People who need them can get them.

Joe

--
Joe Germuska
Joe@... * http://blog.germuska.com   

"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed.  Try something new."
        -- Robert Moog

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank W. Zammetti]

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@...