struts is described as an action oriented framework for making jsp web application writing more reusable and maintainable, and easier to understand over a long term; whether this would occur with any framework is debatable.

struts application have a struts-config.xml file which basically maps page navigation to labels, and to actions. An action is mapped to various labelled outcomes e.g. success, failure, retry, optional1, which are mapped to other pages. The problem with the action oriented approach is that post processing of a page seems to occur in the action, but as well as the pre processing for all the possible outcomes , all in one action. An advantage though, is that the action has a third purpose , which is to set up java view "beans" , basically classes with get/set methods, so that some effort is made to map out the view in a data organizational way, before the details of how the items of data are iterated over and displayed are done, so one doesn't get jsp pages full of array constructing, sql statement executing, resultSet iterating code, mixed in with working out what colour and width a table cell/column is going to be.

A more recent java framework is the jsf specifications framework, most openly implemented in the myfaces package of the apache org site, which has version 2 apache license, which is less formidable than a sun license. The JSF framework is said to be component oriented, as opposed to action oriented. The framework still has labelled outcomes, connected to pages to head to, in a faces-config.xml file, but the javabeans have a more active role to play. The java beans are also specified more openly at the start of the faces-config.xml, and called "managed beans" . Form actions and hyperlinks are implemented as action events, parametized sometimes with a name, and a few other attributes, e.g. id, and sent to event handlers , or in java lingo, event listeners. These event listener methods, are often on the bean class itself, so that further events or processing can occur on the values entered on the bean class, when the action event is issued. e.g. read the bean properties which correspond to table attributes, and insert or update a table row. The outcome of an action event is not "void" , but a string, and that string should be returned by the event listening method, and it is the key that determines where the faces-config.xml rules navigate to next. One difference , is that the setup of beans is done near the configuration time of the application, so what beans are present is more obvious, as compared to struts, where beans could be created in any action in the pre -next page processing phase . There are such things as "phase" listeners , so that setup for a view , might be more associated with the page , rather than an alternative pre-next view processing occuring in a number of action listeners. But it can be argued that the ability to get any bean that has been declared as being "managed" in the faces-config file, via a lookup of application / session /request context, means that pre processing methods are partitioned according to the backing bean of a view anyway, so that in a sense, the event listener methods only define the detail of a global state change of the single model tree anyway. Another noticeable difference is how iteration to display a compound view (e.g. a table ) is done . The table specifies a reference to a list or sequence / iterable collection attribute on the backing bean, and a iteration variable, and then a subview that will be used to display each item. The conditional part of display must be contained in attributes of each iteration item e.g. a "isDisplayed" attribute, for sparse arrays like appointment days. This would make the view jsp pages enforceably tidier.

-- SyanTan - 13 Jul 2006
Topic revision: 13 Jul 2006, SyanTan
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark