• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Struts 2

 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello David Newton-

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?

Thanks,
David
 
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

There's a page comparing Struts 1 and 2 on the Struts 2 documentation wiki that highlights many other differences.

I've used Struts 1 since 1.0 (pre-1.0, I suppose) and there's just no comparison. There are a few pain points, but overall, it's been a much better experience for me.

Dave
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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???
 
David Newton
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.

Dave
reply
    Bookmark Topic Watch Topic
  • New Topic