Does Struts really need two frameworks? (long)

[Don Brown-2]

I'm suggesting something bigger: Struts 2.0.  This release will come with SAF2,
Shale, Tags, and maybe Action 1.x for legacy reasons.  We would continue to
develop SAF2, Shale, and Tags, but the world would just need to see Struts 2.0.
  Its documentation will tie the projects together and provide coherent advice
on how to write a simple application (using Action 2 and either Action 2 tags or
JSF) to when to use what library where.  This release would be the one-stop-shop
for users wanting to use the latest "Struts" has to offer.  It goes back to
Struts' roots as a single solution for web development needs.

Don

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

[craigmcc]

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

>
> I'm suggesting something bigger: Struts 2.0.  This release will come with
> SAF2,
> Shale, Tags, and maybe Action 1.x for legacy reasons.  We would continue
> to
> develop SAF2, Shale, and Tags, but the world would just need to see Struts
> 2.0.
>   Its documentation will tie the projects together and provide coherent
> advice
> on how to write a simple application (using Action 2 and either Action 2
> tags or
> JSF) to when to use what library where.  This release would be the
> one-stop-shop
> for users wanting to use the latest "Struts" has to offer.  It goes back
> to
> Struts' roots as a single solution for web development needs.

Would you anticipate the bundling would just be "the latest and greatest
released version of each piece" or some sort of coordinated simultaneous
releases?  The latter doesn't sound feasible, given our track record with
getting things out quickly even by themselves :-).

Don


Craig


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

[Don Brown-2]

Craig McClanahan wrote:

> On 6/21/06, Don Brown <mrdon@...> wrote:
>>
>> I'm suggesting something bigger: Struts 2.0.  This release will come with
>> SAF2,
>> Shale, Tags, and maybe Action 1.x for legacy reasons.  We would continue
>> to
>> develop SAF2, Shale, and Tags, but the world would just need to see
>> Struts
>> 2.0.
>>   Its documentation will tie the projects together and provide coherent
>> advice
>> on how to write a simple application (using Action 2 and either Action 2
>> tags or
>> JSF) to when to use what library where.  This release would be the
>> one-stop-shop
>> for users wanting to use the latest "Struts" has to offer.  It goes back
>> to
>> Struts' roots as a single solution for web development needs.
>
>
> Would you anticipate the bundling would just be "the latest and greatest
> released version of each piece" or some sort of coordinated simultaneous
> releases?  The latter doesn't sound feasible, given our track record with
> getting things out quickly even by themselves :-).

The former :)  This would be the latest and greatest, ideally at 6-9 month
intervals, although that timeframe could just be me dreaming :)

One point of clarification - when I talked about the common narrative of a
simple app using Action 2 and using both JSF and SAF2 tags, I mean that as a
demonstration of a simple application using the "best" of Struts 2.0.  I don't
expect the committers to agree it is the "best" way to develop a simple app, as
I don't think that is a realistic expectation.

Don

>
> Don
>
>
> Craig
>
>
> 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?
>> >
>> > -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@...

[Paul Benedict]

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

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



 
---------------------------------
Yahoo! Sports Fantasy Football ’06 - Go with the leader. Start your league today!

[Ted Husted-5]

On 6/21/06, Don Brown <mrdon@...> wrote:
> It goes back to Struts' roots as a single solution for web development needs.

:) Hmmm, I think you would need to look to Matt Raible's stuff for that :)

Historically, people always *wanted* Struts to be a single solution,
but we always tried to discourage that notion. Instead, we encouraged
extensions to Struts, like Struts-Layout and Struts-Menu and
Struts-Velocity, and dozens of others, so that we wouldn't bloat the
core. Recently, we've continued that trend by extracting Tiles into a
standalone product.

Right now, today, both SAF2 and Shale are as much a single solution as SAF1.

If we wanted Struts 2.0 to be a true omnibus product, then it should
include a data access solution, a data indexing solution, a menuing
solution, a security solution, a wizard solution, and an (even better)
AJAX solution. We're not even coming close to bundling everything a
*real* web application uses these days.  Witness that applications
like Confluence and Roller need to add to the mix.

Bolting JSF onto SAF2 would be helpful to many teams who just want to
use a few JSF components, or who would like to get their feet wet
without diving in. But adding Shale to the mix doesn't suddenly make
SAF a "single stack solution" a la Ruby on Rails. That's a whole
'nother jungle :)

It would demonstrate that SAF2 can be an omnibus controller, but it
wouldn't transmigrate Struts 2.0  into a one-stop shop.

-Ted.

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

[Ted Husted-5]

On 6/21/06, Patrick Lightbody <forum-struts-dev@...> wrote:
> 2) Shale becomes a TLP. We continue to share code and ideas where it makes sense,

Or, in other words, the same relationship we have with XWork, OGNL,
FreeMarker, JasperReports, and Dojo.

-Ted.

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

[Don Brown-2]

Ted Husted wrote:
> If we wanted Struts 2.0 to be a true omnibus product, then it should
> include a data access solution, a data indexing solution, a menuing
> solution, a security solution, a wizard solution, and an (even better)
> AJAX solution. We're not even coming close to bundling everything a
> *real* web application uses these days.  Witness that applications
> like Confluence and Roller need to add to the mix.

Actually, this is where I'd like to see it go, and in fact, when talking about
Ti at the start, I had envisioned bringing in Appfuse-type capability.
Furthermore, at JavaOne this year, I talked to Matt about just that.  However,
that is a whole other undertaking and we need to get GA releases of Shale and
Action 2 out first, so for starters, Struts 2.0 would be a bundling of all
Struts subprojects and unified documentation.

Don

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

[Don Brown-2]

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

[Michael Jouravlev]

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.

Making a following analogy

SAF1 ~ Win16 API
SAF2 ~ Win32 API
JSF ~ .Net
Shale ~ WinFX

I see how WinFX enhances .Net, and how .Net works together with Win32
talking to each other as well as to the same core API. But I do no see
how WinFX can be a part of Win32 or why it should be shipped with
Win32. Unless, of course, everything is bundled together in one huge
lump of code.

On another note: I hope that SAF1 has not reached WinMe stage, and is
still somewhere along Win98 lines ;-)

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

[Paul Benedict]

Don, I suppose I generally agree with you.... I guess. The problem is, which always seems to be the case here in this group, is that every year someone is trying to answer the question: "What is Struts really about?" At first it was an action framework, and then it was a JSF framework, and then it was dual frameworks, and now it is ... what? Depends on who you ask on this mailing list :-) It's the never ending question.

Solutions are fine. Our obvious disarray on what "Struts" is, is not. When you look into Spring, what kind of "struts" actions do you have? You have those for the Action framework. It is pretty solidified in the minds of developers that Struts = Action Framework. I haven't seen anyone in my life ever go out of their way to say otherwise. Say the word "Struts" and they know exactly what it means: the action framework.

But people talk about Shale as not Struts. They don't say "not Struts" but it is always the implied point that it is a different product, and I'd be lucky if someone says "Struts" in front of Shale. Except when people want to be really legalistic, most people just say "Shale" -- the general attitude is that it is really a different product. Hence, the email chain "do we really need two frameworks?"

So what is the real Struts? :-) This email chain has thrown around so many ideas where Shale belongs... an"omnibus", under MyFaces, a new TLP, etc.... I hope packaging it all together isn't a way out of this debate :-)

Paul

 
---------------------------------
Ring'em or ping'em. Make  PC-to-phone calls as low as 1¢/min with Yahoo! Messenger with Voice.

[Ted Husted-5]

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

-Ted.

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

[Gary%20VanMatre]

>From: "Ted Husted" <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@...
>

[Dakota Jack]

This is the same thing except giving the real problem, JSF force fit into
Struts, more importance.  This intensifies rather than solves the problem.
Action and JSF are two different web frameworks.  That is the bottom line.
Adroit talk, fancy speeches, etc., cannot change that and only serve to
diminish the little confidence people have in those who try to talk the
problem away instead of solving it.  Let JSF make its own way.

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

--
"You can lead a horse to water but you cannot make it float on its back."
~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?

On 6/21/06, Gary VanMatre <gvanmatre@...> wrote:

>
> >From: "Ted Husted" <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~

[Dakota Jack]

I laughed when you were made a committer, Michael.  That convinced me that
the end was inevitable.  However, this I don't find at all funny.  I really
would like to see Struts succeed.

On 6/20/06, Michael Jouravlev <jmikus@...> wrote:

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

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

[Dakota Jack]

Why in the world cannot you people see that JSF just does not fit?  Is it
impossible to accept the truth?  Would Craig be too angry?

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

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

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

[Dakota Jack]

That's right.  The problem is the presence of any and all JSF hacks.

On 6/21/06, Alexandru Popescu <the.mindstorm.mailinglist@...> wrote:

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

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

[Dakota Jack]

Struts is not advocating a preference?  The Orwellian Speak continues.
Struts is Action.  Struts is NOT JSF.  Struts does not have a preference
because Struts IS one of the alternatives and one of the alternatives is NOT
Struts.  I get a kick out of Don calling people willing to state that the
king has no clothes are radical.  The people who are not radical are the
people willing to tell the half truths to keep Craig, and other JSF career
dependent people, happy.

On 6/21/06, Ian Roughley <ian@...> wrote:

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

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

[Konstantin Priblouda]

( I send this off list - I hate struts flamewars )
Jack,  

you are saying right things  to people who fail
to understand them...

Struts was already brain-dead  in 2001, and they
will fail to assimilate webwork properly.
(I will be first in line to fork it or apply to
comimter status at opensymphony, or use my time
and commiter powers to improve nanowar)

I think your skills are better used on improving
freemarker ;) ( since velocity guys are not doing
their work at all... )

regards,

--- Dakota Jack <dakota.jack@...> wrote:

> I laughed when you were made a committer, Michael.
> That convinced me that
> the end was inevitable.  However, this I don't find
> at all funny.  I really
> would like to see Struts succeed.
>
> On 6/20/06, Michael Jouravlev <jmikus@...>
> wrote:
> >
> > 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@...
> >
> >
>
>
> --
> "You can lead a horse to water but you cannot make
> it float on its back."
> ~Dakota Jack~
>

----[ Konstantin Pribluda http://www.pribluda.de ]----------------
Still using XDoclet 1.x?  XDoclet 2 is released and of production quality.
check it out: http://xdoclet.codehaus.org

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

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

[Dakota Jack]

Heh, I have an idea, since JSF is so independent, why don't you start an
open source project for JSF? Then we could see if people really want it and
we could begin to tell what in the h  -- e -- l -- l is going on with
Struts.

On 6/21/06, Craig McClanahan <craigmcc@...> 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.

I agree, except for the suggestion that Struts, rather than JSF, is heavy
weight.  JSF is a misguided attempt to turn HTTP into Swing.

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.

Can't people see how nuts this whole talk is?  Craig is the author of the
problem that is faced here.  Why would you think he can be the solution.
This is all terribly neurotic at best.

To me, it does not make sense for a framework to say "I adopt JSF"


A framework cannot adapt JSF because JSF is a framework.  Lord!


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 :-).

Heh, I have an idea, since JSF is so independent, why don't you start an
open source project for JSF?


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 :-)



Why not migrate on over to your own  open source  space?  There's an idea if
you think that JSF is so good.  Compete fairly and see whose toushckiss gets
smoked.

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 get a real kick out of calling this dead horse with a huge history (that
is JSF) the future.  The failure for the past 6 years is 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.

O-O bigots?  What a joke.  You try to sell a tool oriented kit for dummies
and call us people with a real interest in the theory bigots?  Why don't you
run away and try to earn your own keep?  If JSF is so good, why cannot it
find a way to succeed apart from Struts?  Where is the great JSF community
out there that is not trying to survive by hopping on this framework or that
framework?  Why is JSF, that old man, so devoid of any space by itself?  The
reason is because it sucks.

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

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