Hi, First of all, I want to thank everyone for their responses. I was concerned that the questions I posed could be misinterpreted as an attack on Struts and usefulness of the framework, and that I would get some heated responses. However, everyone only tried to help me better understand the issues I was struggling with. Its a very nice and helpful mailing list here.
I agree that there should not be one solution for every possible need. It makes sense that standardizing on such a level would create an overly confined environment. So a framework such as Struts is built on top of the servlet specification. One issue that can come up in such a situation though, is that the framework can somewhat isolate its users from the changes and additions to the underlying specification. These changes might be useful, but since the framework was built on top of the older version of the specification, using these changes does not come naturally in the framework. After enough of these changes have accumulated, it might be helpful to rework that framework to make use of those additions, and to expose them to the users of the framework. That would probably result in an improved framework that would fits better with the current state of the specification it is built on top of. Of course I say this out of desire to always use the latest stuff without having to worry about backward compatibility and the huge user base :). Some people have it easier than others :). ranko -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 2:51 AM To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: RE: Struts MVC framework similar to that of a servlet container? On Tue, 22 Jul 2003, Andrew Hill wrote: > > <snip> > all this great filters in place of ActionServlet direction > </snip> > > I could be wrong about that, thats just the impression I get from the posts > and discussions here and on the dev list. It seems a logical conclusion > though. > Herein lies one of the realities of standards-based development -- standards never evolve as quickly as some people would like. For others, though, standard evolve far too quickly and eliminate the opportunity to compete! For better or for worse, Struts 1.x is going to remain based on Servlet 2.2 and JSP 1.1 as the base technologies, for as long as people listen to me (I *hope* that will be for a while yet :-). You see, the other side of developing a widely adopted technology (even if it's only a "de facto" standard instead of an "official" standard) is that it's totally unreasonable to abandon your users and customers who have committed substantial effort and expense to building applications based on that platform. If we (the Struts developers) were to say "sorry, folks, but 1.1 is the end of the line for software that will run on your J2EE 1.2 server", they would have a very justifiable reason to abandon Struts. But that's not going to happen. Ranko, Struts came into existence in the first place to provide a single solution to a series of problems that a very large number of people have had -- how do I architect a large scale web application so that the cost of maintenence doesn't kill me? Indeed, one of the most common comments on the Struts mailing lists in the early days was "I was just building something like this ... I'm delighted that I can adopt a common standard so that I can focus on building software for *my* application, instead of reinventing standard infrastructure." The servlet API did not then, and does not now, provide all the capabilities needed to meet all of those needs in a "Java standard" way. As I described in my earlier message, though, the right answer is *not* to extend the Servlet API to do this -- instead, it is to create standardized frameworks for all of the relevant use cases, on *top* of Servlet. There is more than one need. There is no such thing as *any* single framwork that is going to be able to meet all of them. Craig --------------------------------------------------------------------- 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]
