----- Original Message ----- From: "Andrew Hill" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Wednesday, July 16, 2003 5:20 AM Subject: RE: what the webwork guys say about struts
> <snip src="wiki.opensymphony.com"> > WebWork's pros include being a smaller, simpler framework, not having to > build ActionForm beans, making it very simple to test your Actions, having > multiple well-supported view technologies, simpler views with less JSP tags > and a more powerful expression language, not having to make your Actions > thread-safe, not having your Actions tied to the web, and not being part of > Jakarta J. WebWork2 also adds many new features such as Interceptors, > packages, IoC, etc. WebWork's cons include being a smaller project with > fewer books and less tool support, having less standards support for specs > like JSTL and JSF, and not being part of Jakarta > </snip> > > Fair enough to a point, but Id definately disagree about struts not > providing good support for using other views. There is nothing in struts > that specifically makes it hard to support other view technologies - the > taglibs that come with struts are purely a convienience for the majority who > use JSP (theres a good argument to make them a seperate download imho) - but > theres nothing anything to stop you using other things. Many people use > velocity with struts - its a good fit from what I hear, and you could use > pretty much any other technology too so long as that technology doesnt > depend on some proprietary framework to be used with it (which would affect > WW also). All the struts config objects are accessible from the servlet > context and there are even toolkits for technologies such as velocity... I > personally use my own homebrew rendering technology (which basically is just > leveraging DOM and xhtml) and found that struts didnt get in the way and > indeed meshed nicely in many cases. > > What I saw in the good 2 minutes or so I looked at WW just now that _did_ > get me excited was the idea of it making it much easier to seperate classes > from dependancies on the servlet api thus becoming easier to test. One can > always test struts with things like StrutsTestCase or cactus doing mock > object or in container tests, but learning how is a daunting task, which Id > imagine has put off many people from trying. (I know Ive never bothered to > work out how to do it - but hey, my codes so good it doesnt need testing > right? ;->) If it could easily test my stuff in good old Junit using j2se... > that would be sweet mate... > > > <snip> > The mapping from HTTP Request to Actions is really cohesive. You have a > form with fields, you have an action with corresponding fields. > </snip> > > Yes - theres a lot to be said for the idea of merging the actionform and the > action and instantiating a new instance for each request (or reusing one > from the session). Ive never fully grokked why struts was so keen to use the > singleton pattern for actions. Tis true that servlets do this - and actions > resemble servlets (after all they are in the end just the bit of the > ActionServlet that does the specific work!) , but I and others have oft > debated the merits of relaxing the threadsafety rule on actions and > instantiating new ones each time - and merging the actionform into the same > object so that you have a sort of 'component' perhaps follows on from this? Here are my personal interpretations of the Singleton Pattern for Actions: The action class is a nature extension of the servlet with a binding between an html form element and the action. If you consider it a part of the servlet engine, your application would not worry about the singleton issue and you could create instances of whatever objects inside the action, as what you say, just the bit of the ActionServlet that does the specific work. If you think this way, merging the action form and the action would be a *bad* idea, because you could do it inside the action by creating objects without any ties to the web. I guess the JSF has the similar infrastructure, a singleton somewhere that binds components between clients and servers. If that is the case, you do not regard that singleton as a part of your web applications. Having a separate form bean, Struts does not show significant advantages over other frameworks that use command patterns. It has been a debate topic with so-so results. However, the world is not enough on pure server-side development. The separation of form bean, form view, and form controller gives UI experts an excellent opportunity to build elegant user interfaces. Technologies have advanced in a way that any marginal benefits in other frameworks are cancelled out: Our research has produced a block model over the traditional component model. It introduces the concept of Logical Web Form, Carrier Orbit, Publish Time, and Control Page. These concept leaps make SLWS (Super Large Web Service) become possible in which hundreds of thousands of web forms could be designed by the masses on Internet (http://www.netspread.com/tips2.html#building) The concept of Control Page matches the concept of singleton patterns of action in which Carrier provides designers the ability to visually compose business logics, or say, it is a visual scripting environment. So testing individual actions or form beans become unnecessary with such technology. You only need to test your domain objects and logics. The concept of Publish Time is even more powerful (I will describe it later, it could change a thing considered the only correct way today to be wrong in tomorrow) The debate should be over. Let us focus on simplicity, scalability, and productivity at a higher level - the level that includes web tier framework, Java Plug-in, Swing, Java Script or Dynamic HTML all together. Jing Netspread Carrier http://www.netspread.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
