Struts is very robust and widely used framework, but there exists the alternative to the struts framework. Here we have listed the listed the frameworks that can be used as an alternative to the struts framework.
Apache Cocoon is a web development framework built around the concepts of separation of concerns and component-based web development.
Cocoon implements these concepts around the notion of 'component pipelines', each component on the pipeline specializing on a particular operation. This makes it possible to use a Lego(tm)-like approach in building web solutions, hooking together components into pipelines without any required programming.
Cocoon is "web glue for your web application development needs". It is a glue that keeps concerns separate and allows parallel evolution of all aspects of a web application, improving development pace and reducing the chance of conflicts.
Jakarta Struts is a framework that facilitates building servlet applications based upon the Model-View-Controller (MVC) design paradigm. Most Struts applications use a browser as the client, but the framework is actually open enough to allow other client types. In this first article of two, I'll take the browser application from my JavaBoutique article "Coding your second Jakarta Struts Application", and prepare it for adding a Swing client to it--with only a few changes to the code in the original browser application. In the second article we'll see how the coding of the Swing application is done. So this article is about connecting a Swing client to an existing servlet application. If you're planning a new Java application that has to service both a web browser and a Swing client you should consider other architectural alternatives too, for example EJB's, or web services, since they may offer simpler interfaces or additional advantages--all depending on your application's needs. It's outside the scope of this article to compare architectures. But if you're interested in the topic you may find some good opinions at Sun's discussion forum.
Struts for transforming XML with XSL (stxx) is an extension of the struts framework to support XML and and XML transforming technologies like XSL without changing the functionality of struts. stxx sits on top of Struts, extending its existing functionality to allow Action classes to return XML that will be transformed by technologies like XSL and XSL-FO. The idea behind stxx is to remove the need to use JSP and tag libraries for the presentation layer of the Struts framework. However, stxx does not force you to go the XML route, both technologies will work side by side. Struts for transforming XML with XSL (stxx) is an extension of the struts framework to support XML and XSL without changing the functionality of struts.
Velocity is a Java-based template engine. It permits anyone to use a simple yet powerful template language to reference objects defined in Java code.
When Velocity is used for web development, Web designers can work in parallel with Java programmers to develop web sites according to the Model-View-Controller (MVC) model, meaning that web page designers can focus solely on creating a site that looks good, and programmers can focus solely on writing top-notch code. Velocity separates Java code from the web pages, making the web site more maintainable over its lifespan and providing a viable alternative to Java Server Pages (JSPs) or PHP.
Velocity's capabilities reach well beyond the realm of the web; for example, it can be used to generate SQL, PostScript and XML (see Anakia for more information on XML transformations) from templates. It can be used either as a standalone utility for generating source code and reports, or as an integrated component of other systems. For instance, Velocity provides template services for the Turbine web application framework, together resulting in a view engine facilitating development of web applications according to a true MVC model.
WebWork is a Java web-application development framework. It is built specifically with developer productivity and code simplicity in mind, providing robust support for building reusable UI templates, such as form controls, UI themes, internationalization, dynamic form parameter mapping to JavaBeans, robust client and server side validation, and much more.
OpenSymphony and the WebWork team are proud to announce the release of WebWork version 2.2 (download now). This release is the biggest release ever for WebWork and there are plenty of reasons why (full release notes):
Spring's web MVC framework is designed around a DispatcherServlet that dispatches requests to handlers, with configurable handler mappings, view resolution, locale and theme resolution as well as support for upload files. 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, for example AbstractController, AbstractCommandController and SimpleFormController. 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 use any object as a 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, for example, 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 to convert the Strings properly. Instead, it is 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 - for every type of action.
Compared to WebWork, Spring has more differentiated object roles. It supports the notion of a Controller, an optional command or form object, and a model that gets passed to the view. The model will normally include the command or form object but also arbitrary reference data. Instead, a WebWork Action combines all those roles into one single object. WebWork does allow you to use existing business objects as part of your form, but only by making them bean properties of the respective Action class. Finally, the same Action instance that handles the request is used for evaluation and form population in the view. Thus, reference data needs to be modeled as bean properties of the Action too. These are arguably too many roles for one object.
JavaServer Faces Technology
JavaServer Faces technology simplifies building user interfaces for JavaServer applications. Developers of various skill levels can quickly build web applications by: assembling reusable UI components in a page; connecting these components to an application data source; and wiring client-generated events to server-side event handlers.JavaServer Faces technology includes:
* A set of APIs for representing UI components and managing their state, handling events and input validation, defining page navigation, and supporting internationalization and accessibility.
* A JavaServer Pages (JSP) custom tag library for expressing a JavaServer Faces interface within a JSP page.
Designed to be flexible, JavaServer Faces technology leverages existing, standard UI and web-tier concepts without limiting developers to a particular mark-up language, protocol, or client device. The UI component classes included with JavaServer Faces technology encapsulate the component functionality, not the client-specific presentation, thus enabling JavaServer Faces UI components to be rendered to various client devices. By combining the UI component functionality with custom renderers, which define rendering attributes for a specific UI component, developers can construct custom tags to a particular client device. As a convenience, JavaServer Faces technology provides a custom renderer and a JSP custom tag library for rendering to an HTML client, allowing developers of Java Platform, Enterprise Edition (Java EE) applications to use JavaServer Faces technology in their applications.
Little did anyone know, when the first few lines of code were committed to the Struts CVS repository in June 2000, that a revolution was brewing. Prior to that time, there were few useful models for best practices for the architecture of web based applcations. The best we could do was handwaving about "Model 1" and "Model 2" approaches.
The original implementation of Struts, which was released as a 1.0 product approximately one year later, changed all that. As more and more people came to understand the advantages of building on top of a stable and supported framework, and as more and more developers adopted it for their own application development, and as more and more books helped everyone understand how to use the framework correctly, and as more and more development tools provided support for building Struts based applications, the word changed. A small open source project became a defacto industry standard that, even today, is very popular.
But that was then ... and this is now. In the years that Struts has been around (five and counting as of this writing), vastly improved technologies have become available from many talented architects and designers. Moore's Law has continued its seemingly inexhaustible progress. Developers have grown in their ability to understand the benefits of a monolithic controller architecture ... as well as increasingly developing preferences towards agility, code reuse, unit tests, and building applications by composition instead of inheritance.
The major features of the Shale Framework are described in the following detail sections:
Recommend the tutorial