I would not call it persnickety, although there is no immediate problem. My concern is that there is a lot of duplication of funtionality (if there is). If form handling equal to that of Struts was added to the Servlet specification (for example by providing a standard implementation of a Filter to do so given a configuration in web.xml), would it then be equivalent to Sturts?
Basically, it seems to me that much of the framework that Struts provides is already provided by the Servlet specification. If the energy used to develop Struts was used to make JCP somehow make these ease of programing changes that are missing, would we end up with a much better, cleaner, and simpler framework? Or am I completely off here and the MVC framework provided by the container is really not the same as the one provided by Struts. Again, its a general question, I have no pressing need that needs to be addressed. Thanks. ranko -----Original Message----- From: Adam Levine [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 12:49 PM To: [EMAIL PROTECTED] Subject: RE: Struts MVC framework similar to that of a servlet container? for my $0.02. Using just pure servlet and base JSP, dealing with forms is not intuitive or clean. You either rely on too much code in a JSP, or too much reading and parsing at the start of your servlets. And, the development cycle increases as your changes increase. I find the Struts mode to be clean and simple. Need to change a field, add a field. Change one class (the ActionForm, or not at all with a dynaform), modify the .jsp presentation. And then account for the field change in the business logic. Combine it with XDoclet, and you've got immediate Data/Value Objects that can be generated from the ActionForm itself, ready to be passed back to your EJB level code (using CMP, you never have to account for the field in the logic, unless you're doing business level decisions). The mechanisms in place for detailing messages back to the user (ie, ActionErrors) are very clean, easly integrated with field-specific messages. Seamless integration with Java's i18n functionality. >> I'm looking for the reasons why this would not be the case. Are you looking for where using the base Sevlet layer is more advantageous over using Struts? Or, are you looking for areas that Struts just doesn't handle, leaving a gaping hole? Are you being persnickity, or is there a serious question/concern ? From: "Ranko Bijelonic" <[EMAIL PROTECTED]> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Subject: RE: Struts MVC framework similar to that of a servlet container? Date: Mon, 21 Jul 2003 12:38:22 -0400 Yes Struts does definitely solve many problems and make it easier. But is seems that it solves a lot of problems that are already solved. I'm looking for the reasons why this would not be the case. Thanks for the help, ranko -----Original Message----- From: Sandeep Takhar [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 11:21 AM To: Struts Users Mailing List Subject: RE: Struts MVC framework similar to that of a servlet container? I guess the main difference between what you mention and struts is that you can use this stuff right away for the app you want to build without modification. As long as you understand the concepts you can apply them. Similar to how you understand a servlet/filter spec. Now you have common problems solved. You don't have to code them or copy and paste from somewhere. You also have the ability to auto-populate to lists which is pretty neat. sandeep --- Ranko Bijelonic <[EMAIL PROTECTED]> wrote: > > there's a lot of stuff it gives you out of the > box. > > > 1. solid code > so does the container i guess. > > >2. validation framework > This is one of those changes that could be added by > way of utility classes. > Have that Filter that autopopulates, check for > correct types like Struts. > > >3. tile framework > You can use it without Struts > > > 4. auto-population framework > It should be easy to add a Filter that autopopulates > a configured form (not > every time but as a standard). > > > 5. role based actions > I'm not sure what this is. > > >6. xml configuration of all the links or actions of > your application > So does web.xml i guess. > > >7. best practices framework bundling (scaffolding) > complete with examples (many years of experience > went > into this one). > Same thing as above. There are tutorials, examples, > etc... > > > > 8. ease of use > If you think of a Servlet as an Action its kind of > as easy. Except for some > repetative tasks that I would include to complete > the servlet spec (rather > than rewrite some of the container functionality to > add those utils). > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Monday, July 21, 2003 8:42 AM > To: Struts Users Mailing List > Subject: Re: Struts MVC framework similar to that of > a servlet > container? > > > > Sandeep, > You mentioned role based actions in your list... > which has caught my eye. > Can you please elaborate on this ? Or point me to > some documentation ? > > thanks > -raj > > > > > "Sandeep Takhar" > <[EMAIL PROTECTED] To: > "Struts Users > Mailing List" <[EMAIL PROTECTED]> > ahoo.com> cc: > > Subject: Re: Struts MVC > framework similar to that of a servlet container? > 21/07/2003 06:08 > PM > Please respond to > "Struts Users > Mailing List" > > > > > > > there's a lot of stuff it gives you out of the box. > > 1. solid code > 2. validation framework > 3. tile framework > 4. auto-population framework > 5. role based actions > 6. xml configuration of all the links or actions of > your application > 7. best practices framework bundling (scaffolding) > complete with examples (many years of experience > went > into this one). > 8. ease of use > > I am missing about twice as many things from this > list > I am sure... > > the servlet container is sun's way of making sure > that > what you build is timeless (and works on their > servers...) > > Struts solves common problems across every typical > application. The servlet container does not solve > these typical problems. Struts is really a > pattern... > > sandeep > --- Ranko Bijelonic <[EMAIL PROTECTED]> wrote: > > > > Hi. I've been using Struts for a long time, and > > I've been very happy with > > the framework. However, a recent discussion on > > Sun's Java forums has left > > me wondering if Struts is necessary. It seems > that > > the servlet container > > itself provides an MVC framework very similar to > > that of Struts. All that > > is missing is some utilities and standardization. > I > > was wondering if there > > is a flaw in my logic below, and if anyone had any > > comments. > > > > > > In comparing these two MVC frameworks, the servlet > > container would be the > > equivalent of the ActionServlet. They both read > > their configuration files, > > examine the incoming URL, and then forward the > > request to the configured > > handler. In the case of the servlet container the > > handlers are Servlet > > classes, and in the case of Struts its the Action > > classes. Both the > > container and the ActionServlet will create an > > instance of their handler > > when its requested the first time. The Servlet's > > service method and the > > Action's execute method will call some domain > logic > > and then select a view > > to display to the user. The Servlet can use > > RequestDispatchers to > > encapsulate information about the view, and the > > Action will use an > > ActionForward. Doesn't this sound very similar? > > > > It seems like we are adding a lot of complexity on > > top of the servlet spec > > in order to get some common tasks done for us. > But > > that could probably be > > better done by the servlet container itself. For > > example, Struts > > automatically populates the form class the > developer > > specifies for a > > particular Action. But Sun could provide a > standard > > Filter implementation > > which does the same thing. You can declare > handlers > > for your exceptions in > > the Struts configuration file, but you can also do > > it in the web.xml. If > > the functionality there is not quite the same, Sun > > can add a little to the > > spec and we would get it. > > > > My question is, is an application built in Struts > > really that much more > > maintainable than one built with servlets? Or if > > some common utilities > > provided by the Struts container were provided by > > the servlet container, > > would there be much difference? It seems that > would > > even be simpler. Or > > not? > > > > ranko > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > --------------------------------------------------------------------- > 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] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- 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] _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail --------------------------------------------------------------------- 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]
