Discussions

News: Struts 1.1 Release Candidate 2 released

  1. Struts 1.1 Release Candidate 2 released (13 messages)

    The Struts team is proud to announce the release of Struts 1.1 Release Candidate 2. This release includes some new functionality, but mostly just fixes for a number of bugs which were reported against earlier versions.
    The Struts Team believes that this release is ready for prime time, hence its designation as a release candidate.

    Some info on changes in RC2:

    - Commons-DBCP and Commons-Pool dependencies have been removed
    - RC2 is dependent upon Commons FileUpload RC1. The final release of Struts 1.1 cannot happen until this dependency is updated to a final release of FileUpload
    - Action package: Deprecated processActionForward() because ActionForward is a subclass of ForwardConfig so there's no reason we can't use processForwardConfig() instead
    - and more...

    Details of the changes in this release are available in the Release Notes,
    which can be found here:

    http://jakarta.apache.org/struts/userGuide/release-notes-1.1-rc2.html

    The binary distribution is available at:

    http://www.apache.org/dist/jakarta/struts/binaries

    and the source distribution is available at:

    http://www.apache.org/dist/jakarta/struts/source

    In addition, the library distribution, which contains updated binaries
    without the sample applications, is available at:

    http://www.apache.org/dist/jakarta/struts/library/

    Special thanks to Ted Husted for his help in preparing this release.

    --
    Martin Cooper

    Threaded Messages (13)

  2. validWhen[ Go to top ]

    Does this release contain validWhen for the Validator framework. If not when can we expect it. The site says soon after 1.1 but what does that mean?
  3. validWhen[ Go to top ]

    validWhen has not be included yet. As I remember, David Graham said that this validator will be included in Struts 1.2 only.

    Actually, Just after new RC is released, Struts users reported some problems when occurred when they switched from RC1 to RC2, such as problems with commons-logging, commons-fileupload, Datasources.
    So, it looks like it takes some more time before candidate becomes a truly stable release. Hopefully, it will be soon.

    Regards,
    Sergey Smirnov
    -------------------------------------
    Exadel Struts Studio - IDE for Struts
    http://www.exadel.com/strutsStudio
    -------------------------------------
  4. validWhen[ Go to top ]

    I wish to add multiple values to the logic:equal tag

    <logic:equal property="x" value1="abc" value2="bde" value3="edg" ...>
    </logic:equal>

    Is it possible?
  5. validWhen[ Go to top ]

    You could use JSTL's <c:if>, e.g. <c:if test="${bean.value == 1 || bean.value == 2 ...}">; which is anyway the recommended way since the logic and beans taglibs are more than well replaced with their equivalents in the JSTL library
  6. Has anyone had a chance to look at Rod Johnson's MVC framework?
    I think Struts is a good framework and the J2EE community seems to agree on that since struts is the most widely used MVC framework. However, Struts is not perfect (no project ever is). However, if there is an MVC web framework that is close to being perfect, it is Rod Johnson's framework covered in the book titled "Expert One on One J2EE Design and Development" which, as I know, is the best practical J2EE book written so far. It is my understanding that the framework in the book is on sourceforge and a final version will soon be released.
  7. Interesting to hear of someone using the Spring MVC framework. I looked at it when the book came out, but I was just trying a switch from Struts to Webwork, and I didn't have time for it. Any brief comparisons you can make of Spring vs. Struts or Webwork?

    Also, regarding the problem of needing multiple values in the logic:equal tag - this is a very good reason to consider Velocity (or similar template language). The Struts tags and the JSTL tags will get the job done, but cases like these, where you need complex conditionals, tend to be very awkward to do in tags and very simple and pleasant to do in Velocity. Using tags for these tasks equates to using XML for programming, and while it may work, it's usually much more awkward to do than it should be.

    Rob
  8. Strict MVC[ Go to top ]

    The correct solution in this case, IMO, would be to define a helper boolean property in the bean which is used by the view (JSP page). Then, you just use
    Java for writing the complex condition. Putting this kind of logical expression in the view, be it JSP or Velocity, really goes against the MVC paradigm.
  9. Strict MVC[ Go to top ]

    The correct solution in this case, IMO, would be to define a helper boolean property in the bean which is used by the view (JSP page). Then, you just use

    > Java for writing the complex condition. Putting this kind of logical expression in the view, be it JSP or Velocity, really goes against the MVC paradigm.


    Great, and what do you do when you want to support another view layer, which may not have the same condition? Conditions that are only needed for the view layer should be evaluated there...
  10. Strict MVC[ Go to top ]

    Great, and what do you do when you want to support another view layer, which may not have the same condition? Conditions that are only needed for the view layer should be evaluated there...


    The JavaBean the view reads from represents a view-specific model. Therefore, you would have a different bean for a different view.
    I think it's usually easier, overall, to not directly access the actual business model from the view layer, but instead to create a view-specific model layer (unless the view is very simple), which adjusts perfectly to the needs of the view. And you don't need to duplicate the model properties from the business model either.
    This is actually quite common in MVC implementations, even in traditional MVC.
    I read somewhere (found on Google when looking for MVC) that MVC should actually be called "MMVC", or "Model-Model-View-Controller", and this seems to be indeed the case when you look at read-world MVC apps.
  11. Strict MVC[ Go to top ]

    The JavaBean the view reads from represents a view-specific model. Therefore, you would have a different bean for a different view.

    > I think it's usually easier, overall, to not directly access the actual business model from the view layer, but instead to create a view-specific model layer (unless the view is very simple), which adjusts perfectly to the needs of the view. And you don't need to duplicate the model properties from the business model either.
    > This is actually quite common in MVC implementations, even in traditional MVC.
    > I read somewhere (found on Google when looking for MVC) that MVC should actually be called "MMVC", or "Model-Model-View-Controller", and this seems to be indeed the case when you look at read-world MVC apps.

    Well, if the only reaon to have a view model is because it makes it easier to evaluate complex conditions (compared to doing it in the actual view) then I think it would be wiser to find a better technology for building views than to introduce a whole new layer.
  12. Strict MVC[ Go to top ]

    This is actually quite common in MVC implementations, even in traditional MVC.

    > I read somewhere (found on Google when looking for MVC) that MVC should actually be called "MMVC", or "Model-Model-View-Controller", and this seems to be indeed the case when you look at read-world MVC apps.

    I personally like the MMVC, and I've been doing it for some it. But there is something that sucks is copying fields..
  13. Strict MVC[ Go to top ]

    This is actually quite common in MVC implementations, even in traditional MVC.

    > > I read somewhere (found on Google when looking for MVC) that MVC should actually be called "MMVC", or "Model-Model-View-Controller", and this seems to be indeed the case when you look at read-world MVC apps.
    >
    > I personally like the MMVC, and I've been doing it for some it. But there is something that sucks is copying fields..

    Yeah, and another thing that sucks is having to re-compile several java classes just because some small detail changed in the view. Especially since the user-interface designer/developer and the model developer might not be the same person.
  14. Interesting to hear of someone using the Spring MVC framework. I looked at it when the book came out, but I was just trying a switch from Struts to Webwork, and I didn't have time for it. Any brief comparisons you can make of Spring vs. Struts or Webwork?


    I'm the lead developer of Spring's web MVC framework, so I'm a bit biased - but I'll try do a comparison nevertheless :-) And of course I know that this a Struts announcement thread...

    I originally considered Rod's initial drop as the cleanest application framework (especially web framework) I had ever seen, building on a very simple but intriguingly powerful foundation. That's why was one of those who approached him to put it in on SourceForge, and turn it into a community effort. In the meantime, the Spring Framework has grown significantly, as we've introduced AOP support, abstract transaction support, localization support, JSTL support, reworked validation, reworked tag library, etc. And as mentioned, after months of intense work and numerous users that work with CVS snapshots, an official 0.9 release is coming soon (end of June).

    First of all, note a very basic issue: In contrast to Struts or WebWork, Spring is an application framework for all layers, offering a bean configuration foundation, a JDBC abstraction framework, abstract transaction support, etc. It is a very non-intrusive effort: Your application classes do not need to depend on any Spring classes if not necessary, and you can reuse every part on its own if you like to. From its very design, the framework encourages clean separation of tiers, most importantly web tier and business logic: e.g. the validation stuff does not depend on web controllers. Major goals are reusability and testability: Unnecessary container or framework dependencies make this very hard.

    Spring's web framework is designed around a DispatcherServlet that dispatches requests to handlers, with configurable handler mappings, locale resolution, and view resolution. The default handler is a very simple Controller interface, just offering a "ModelAndView handleRequest(request,response)" method. This can already be used for application controllers, but you will prefer the included implementation hierarchy, consisting of AbstractController, AbstractCommandController, MultiActionController, SimpleFormController, AbstractWizardFormController. Application controllers will typically be subclasses of those. Note that you can choose an appropriate base class: If you don't have a form, you don't need a FormController. This is a major difference to Struts.

    You can take any object as command or form object: There's no need to implement an interface or derive from a base class. Spring's data binding is highly flexible, e.g. it treats type mismatches as validation errors that can be evaluated by the application, not as system errors. So you don't need to duplicate your business objects' properties as Strings in your form objects, just to be able to handle invalid submissions, or convert the Strings properly. Instead, it's often preferable to bind directly to your business objects. This is another major difference to Struts which is built around required base classes like Action and ActionForm.

    Compared to WebWork: Spring supports the notion of a Controller, an optional command or form object, and a model (normally including the command or form object) that gets passed to the view. Instead, a single WebWork Action object has all those roles. In Spring, command and form objects can be either existing business objects or specialized UI ones. But WebWork requires you do duplicate your business objects' properties in the Action object in any case, mixing validation right into it, and using the same multi-role object for evaluation and form population in the view. For my taste, these are too many roles in one object.

    Regarding views: Spring's view resolution is extremely flexible. A controller implementation can even write a view directly to the response, returning null as ModelAndView. Normally, a ModelAndView instance consists of a view name and a model Map, containing bean names and corresponding objects (like a command or form, reference data, etc). View name resolution is highly configurable, either via bean names, via a properties file, or via your own ViewResolver implementation. The abstract model Map allows for complete abstraction of the view technology, without any hassle: be it JSP, Velocity, or anything else - workarounds like a VelocityServlet are unnecessary! The model Map simply gets transformed into an appropriate format, be it JSP request attributes or a Velocity template model.

    Finally, if you don't want Spring's web MVC, you can combine Struts or WebWork with the rest of Spring - leveraging all the data access and middle tier stuff that Spring offers. Simply start up a Spring root application context via its ContextLoaderListener, and access it via the ServletContext attribute (or Spring's respective helper method) from within a Struts or WebWork action. All the registered beans including all of Spring's services are still at your fingertips, even without Spring's web MVC.

    Oops, quite lengthy ;-) For the sake of keeping this thread Struts-related, I suggest to move intense discussions (beyond short comments) to the Spring mailing lists. Anyway, I hope my remarks made things a bit clearer!

    Regards,
    Juergen

    Spring Framework