This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I work for an organization that is running Websphere with Java 1.4. What is the earliest version of Java Struts 2 will run on? I am using Struts 1.x now. I really like the MVC structure imposed by the Struts framework and the html form-to-bean binding, centralized error handling, etc. What are a few additional benefits available with Struts 2?
Struts 2 does have a set of Java 1.4-compatible jars and I've run Struts 2.0 apps under 1.4 successfully, but it always made me a bit nervous. I don't know about Struts 2.1 and J4. I'd be more concerned about the servlet spec than Java version, really.
If you like the form-to-bean binding in S1 then you'll be pretty happy about the type conversion in S2; blows S1 away in terms of simplicity and conciseness.
The other thing about S2 I really like compared to S1 is the much better separation of the framework from the JEE spec; it's much easier to test S2 actions.
I dont understand why the decision of makind model as control is supported...till now everyone is trying to follow the design patterns and MVC-2 architecture and suddenly struts decide to give a new product in which model and control both will be done by same class.Doesn't this violate the whole point of having loose coupling between things???
I know we have interceptors that can seprate this logic but y this flexibilt should be given to any developer so that he/she can put both modellingand control logic in the same class???
I dont understand why the decision of makind model as control is supported...till now everyone is trying to follow the design patterns and MVC-2 architecture and suddenly struts decide to give a new product in which model and control both will be done by same class. Doesn't this violate the whole point of having loose coupling between things???
We don't *have* to put form properties as action properties. For example, let's say we have a form containing username and password fields. We could write an action like this:
We could just as easily write it like this:
Similarly, the data we expose to the view layer can be wrapped by however many layers of "protection" we want.
The question is whether or not it's worth it: different situations demands differing levels of exposure, protection, and abstraction. The code in the presentation layer is largely the same regardless of which method we use.
In Struts 1 we used ActionForms... but we also shoved a bunch of data into the request from within our actions. Here that data is exposed via publicly-accessible getters and the framework takes care of the busywork for us. IMO this is a better solution.