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]
