Hi, All of this sounds very good. Especially the Filter/RequestProcessor stuff. You are right, many of the features in the servlet spec that are available now were not available when Struts first started. I guess my biggest objection was having two controllers and two sets of handlers (although for a long time it did not bother me at all). But if these new capabilities are used to kind of 'merge' these two controllers and their handlers that would be great.
The community can provide standard Filter implementations for specific things that are done in the ActionServlet, and there would be a standard way to aggregate them. As you said, this would allow for easier addition of third party extensions. The container's mapping capabilities would be used, and Servlets would take the place of Actions. Having a Servlet superclass that all the other Servlets would extend makes perfect sense to me (cause its not a completely separate kind of handler for which the superclass and mapping mechanism would have to be provided). Also, maybe wrapping the ServletRequest with a class that extends SerlvetRequestWrapper would be better than placing the config and other Struts objects into the request as parameters. That way, one of the early filters in the chain can create a StrutsServletRequest which provides getter methods for these objects. After that, filters down the chain and the handler (Servlet) itself can use this new request object to get what they need. This is the kind of thing that I was thinking about. It kind of trims down some duplicate stuff while still preserving all the benefits. what would be really cool, and I know this is hard, but to influence the spec somehow to allow for easier configuration of all of this. This would involve some kind of merging of the capabilities of struts-config.xml and web.xml :). But if this is the way Struts is moving toward, i'm very excited! ranko -----Original Message----- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 11:18 PM To: Struts Users Mailing List Subject: RE: Struts MVC framework similar to that of a servlet container? One of the things to remember is that struts is quite old - back when it was created filters were not part of the servlet spec - so to give struts a place to do its thing (creating & populating the actionform, populating multipart requestwrappers, etc...) before invoking your code, it has all the requests mapped to the actionservlet (later divided into actionservlet and requestprocessor to ease customisation) - which then maps to the actions themselves using struts-config (which also gives a place for all the extra config stuff that cant go into web.xml). The current version of struts (1.1) is designed to support servlet api 2.2 (which despite being ancient is still very widely used!). A future version of struts (2.0 probably) is going to mandate the use of a 2.3 compliant container and the talk is that what is currently done in the actionservlet can be done using filters. IMHO at this point we would be better off using individual servlets instead of actions (though Im not sure how this would effect modules) - and it may be that struts supplies a base servlet class you can extend (to get the various methods that actions provide). Struts-config.xml and all the config objects would still be around - but rather than being passed to the action in a method parameter by the requestprocessor they could be passed to a servlet in a request attribute having been put there by a filter. An advantage of replacing the actionservlet/request processor (well actually there would still be some kind of struts servlet somewhere to help manage the lifecycle of plugins and the like - but requests probably wouldnt map to it anymore?) is that it would ameliorate the current problems associated with trying to use two different 3rd party requestprocessors simultaneously - an issue which has generated the recent discussions about composable requestprocessors over on the dev list. Instead of all the processXXX methods in the current request processor you could simply apply a whole bunch of filters to those things that need them - and in many cases this would make it trivial to mix third party extensions. You mentioned how you could use third party utility libraries to do much of what struts does for you. Of course struts is itself essentially just a third party utility library providing code to help tie your application together (and the way it does this has been proven to be effective and maintainable). Much of what was originally directly part of struts has now been factored out into the commons library - such things as file-upload, beanutils, etc... and other features that were once unique to struts are now provided elsewhere - such as the overlap between JSTL and what the struts view tags do (which incidentally is no coincidence - the one strongly influenced the development of the other!). -----Original Message----- From: Ranko Bijelonic [mailto:[EMAIL PROTECTED] Sent: Tuesday, 22 July 2003 10:54 To: Struts Users Mailing List Subject: RE: Struts MVC framework similar to that of a servlet container? Its not so much paving of one's own roads, but recongnizing that the roads have been paved already :). I'm not suggesting redoing what Struts does, what I'm saying is that Sturts is redoing what the servlet continer alredy does (for a significat part). By the way, does anyone use filters, events, or request/response wrappers with Struts? I'm just wondering. -----Original Message----- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 10:46 PM To: Struts Users Mailing List Subject: Re: Struts MVC framework similar to that of a servlet container? ----- Original Message ----- From: "Ranko Bijelonic" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>; "Jing Zhou" <[EMAIL PROTECTED]> Sent: Monday, July 21, 2003 8:31 PM Subject: RE: Struts MVC framework similar to that of a servlet container? > >I am getting more clear about your thinking. But saying both (container and > >Struts) are MVC frameworks is not accurate in my opinion. Because a > >container provides you only a 'C' in the MVC pattern; Struts provides you > >action controller ('C') and form bean ('M') and custom tags in JSP pages > >('V'). > > The custom tags (especially now with JSTL) can be used with the container > 'C' also. So now we are left with 'M'. There are no counterparts of the Struts html tag library in JSTL. So we can't reach the conclusion so quickly. JSF is supposed to offer that. But it is not born yet. > I don't consider form beans to be the model, or the whole of the model. > However its much closer like that. > You are right. That is the problem of the current form bean model in Struts 1.1. However, one of benefits of staying with Struts is that you have more choices than you pave your own roads. For example, we have form bean model that is qualified as level one model (12 standard types are supported, not just string). The Struts users may not want to use it today, but they have the CHOICES. Someday for some reason, some of them may use it. If someone paves his own roads, the choices are up in the air ... That is my point. Of course, for a particular individual or project, the choice might not be that important. Jing > -----Original Message----- > From: Jing Zhou [mailto:[EMAIL PROTECTED] > Sent: Monday, July 21, 2003 7:14 PM > To: Ranko Bijelonic; Struts Users Mailing List > Subject: Re: Struts MVC framework similar to that of a servlet > container? > > > > ----- Original Message ----- > From: "Ranko Bijelonic" <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]>; "Jing > Zhou" <[EMAIL PROTECTED]> > Sent: Monday, July 21, 2003 5:03 PM > Subject: RE: Struts MVC framework similar to that of a servlet container? > > > > >It is my understanding that the servlet spec, jsp spec, and jsf spec are > > >regarded > > >as the framework of frameworks (a kind of interpretation of mine) Struts > > >action mapping is designed in Struts way. If the struts-config.xml is > > merged > > >into the web.xml, a lot of other frameworks would not happy :-) How do > > >you solve such problems from the perspectives of spec leads, when you > > >realize Struts way is only one way? I guess they have to investigate a > lot > > >of > > >frameworks before committing one way (a 2 to 4 years effort). > > > > >I presume your TaskAction is a more refined controller than the Struts > > >Action. It should understand event types, command name, etc. from the > > >http requests in order NOT to overlap the functionality of the Struts > > >Action. > > >The Struts Actions could recognize the task-config.xml and execute > > >configured TaskAction(s) in a workflow manner. In other words, the > > >Struts Actions are used to declare what to do, your TaskActions are > > >used to specify how to do. > > > > >Does this address enough specific questions you have? > > > > I'm not saying that the container should adopt the way Struts does things, > > but that Struts does things in the same way the container does :). Both > are > > MVC frameworks wich delegate processing to configured handlers. Its looks > > like its the same thing already. > > I am getting more clear about your thinking. But saying both (container and > Struts) are MVC frameworks is not accurate in my opinion. Because a > container provides you only a 'C' in the MVC pattern; Struts provides you > action controller ('C') and form bean ('M') and custom tags in JSP pages > ('V'). > > In addition, Struts partition one web application into application modules > for higher scalability of engineering processes. You could not achieve this > using only web.xml. > > > Ok, so do these extensions that I have built into my more refined > controller > > warrant rewriting the controller itself, or should I just try to extend > > Struts somehow to handle this extra functionality. Take DynaActionForms > for > > example, its usage is similar to that of a ServletRequest. I ask for a > > parameter/property by name and I get an Object. It might have some more > > functionality, but that could have been added by extending > > ServletRequestWrapper just as easily. I don't know. It just seems things > > could be simpler while maintaining all of the benifits of Struts. > > The dyna form is *similar* to a ServletRequest. But it could be nested > inside other form beans in addition to its configurable properties. A simple > ServletRequestWrapper would not make the *whole* job disappeared if you > do not use the common's beanutils. > > But it did invoke scaring thoughts at early time when people thought the > benefits of dyna forms are marginal to a ServletRequest. But technologies > advance, much powerful form bean model has been designed ... > > > > > ranko > > > > Jing > > > > > --------------------------------------------------------------------- > > 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] > > --------------------------------------------------------------------- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
