Ted,
I hope you don't think that we (well me at least) seem to be accusation in our e-mails. That is not the case. I am just sharing my thoughts on where this or that approach might lead in the future. It might sound unappreciative when guys spend thousands of hours perfecting/making better something and other guys try to critique it without knowing what labor was put into this work, but that's the nature of users: bitch, bitch, bitch (I know it myself). No hard feeling I hope :)
Ted Husted wrote:
I don't think anyone is out to prove or disprove anything.
Craig saw a cool way to implement a front controller for JavaServer Faces, so he posted some proof-of-concept code. Other people starting making contributions. A community is growing up around the codebase, so we made it a subproject. That's really all there is to it.
You know, guys, most of the committers are working stiffs, just like you. We find ways that help us write our own applications, and we share them with the community. We're not sitting around trying to come up with "The Next Big Thing" and move another million of copies of Struts. We're just trying to ship our next application, while we maintain the ones we already go, just like you.
Craig thinks JSF and Shale is a great way to write Java Web applications, and other people are starting to agree with him. That's not to say there are not other great ways to write applications. Tapestry is one. Maverick, Spring MVC, and WebWorks are others.
-Ted.
On Wed, 02 Feb 2005 09:34:54 -0500, Alex Kravets wrote:
Ted, Graig,
So was Struts Shale made to make programmer's life easier in creating Web Applications using MVC Framework? I've read some posts/blogs where people who've used Struts and now use Tapestry say that they will never go back to Struts again. Is this what Struts Shale tries to change/disprove?
Ted Husted wrote:
On Mon, 31 Jan 2005 17:03:09 -0500, Alex Kravets wrote:
So what do you guys think? http://www.theserverside.com/news/thread.tss?thread_id=31509
An important clarification we'll make to the FAQ is that "by doing our job right" we mean "not break backward compatibility" in the ongoing 1.x series.
There's more than a few things that people want to do with Struts 1.x yet. We're approaching Struts 1.3, and already, the Milestone page [http://struts.apache.org/milestones.html] is looking forward to Struts 1.6.
If need be, we can go on to Struts 1.42 or Struts 1.2025. If there's interest, there could be another five, ten, or fifty years of Struts 1.x development.
A year ago, we talked about a Struts 2.x revolution to give us a clean start on the codebase. But, most everyone wanted to evolve the Struts 1.x codebase instead.
So, that's what we are doing: evolving Struts 1.x, step by step, innovation by innovation, deprecation by deprecation :)
If we never break backward compatibility, and we never start a new codebase, then we never need to roll the major version number.
Meanwhile, another potentially great framework has come along: Shale. Like Struts, Shale is MVC web framework, but it doesn't share any code or architectural hallmarks with Struts 1.x. We could call it Struts 2.x, but we could also fork Maverick, Spring MVC, Tapestry, or WebWork and call any of those Struts 2.x, if that's what the community wanted.
But, as near as we can tell, that's not what they community wants. The volunteers are showing by their commits that we want to evolve Struts 1.x and, at the same time, also work on Shale 1.x.
As someone mentioned elsewhere: different strokes for different folks: different technologies for different requirements.
People wanted to do both and proved it with their commits. So both is what we are doing :)
And, if someone comes up with a third thing, based on dynamic ECMA Script or something, maybe we'll do that too. :)
-Ted.
------------------------------------------------------------------
--- To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
