- The JavaServer Faces is a component model. Components are event driven and the events generated by the components are handled by the JSF framework in various phases, unlike the JSP expression which will be evaluated immediately. This is called post-back of events. At different levels, different events will get executed like Validations, Conversions etc., which are become major limitations in using the JSP expression language.
- The immediate evaluation will be done on static objects where as the JSF components require the get and set operations on the data objects stored on the server side beans.
- The JSF components are much powerful which require direct execution of methods on the Managed Beans. Also they need to get the data during the render phase and set the data in the beans during post-back.
- Another problem they sought is registering of the various events with their methods on the server side objects which will be executed during various phases.
In ordered to overcome the above limitations, they have developed a new expression language for JavaServer Faces technology which can evaluate expressions at different phases of the application, which can get and set the data on server side objects, which can invoke the methods on the server side objects.
The expressions in EL shall be written by enclosing the expression in between "#{" and "}" literals.
e.g.
If you want to use your Custom Request Processor along with your Tiles Request Processor it will give the error.
This error comes when you extend your custom request processor from the RequestProcessor class. This is because of the bug in Tiles Specification which forces us to write our own custom request processor, for which the TilesRequestProcessor must be the superclass. So if you want to use your custom request processor, say for example using Struts Faces, you must extend the TilesRequestProcessor.
For example, I want to use the JavaServer Faces along with the Struts. So I am using Struts Faces to integrate both Struts & JavaServer Faces. So every request from the jsp should be processed by the Faces Request Processor. So in my web.xml, I write the controller for them as below. Note that the controller processorClass has the value FacesTilesRequestProcessor which extends the TilesRequestProcessor.
<controller>
<!-- The "input" parameter on "action" elements is the name of a local or global "forward" rather than a subapp-relative path -->
<set-property value="true" property="inputForward">
<set-property value="org.apache.struts.faces.application.FacesTilesRequestProcessor" property="processorClass">
</controller>
<plug-in classname="org.apache.struts.tiles.TilesPlugin">
<set-property value="/WEB-INF/tiles-defs.xml" property="definitions-config">
<set-property value="true" property="moduleAware">
<set-property value="true" property="definitions-parser-validate">
</plug-in>
The most ccommon exception when using Tiles in a Struts application is theJasper Exception. For example look into the exception below.
javax.servlet.ServletException: Can't get definitions factory from context
This exception can occur if the Tiles Servlet entries are wrong. We can easily solve the exception by modifying the Tiles servlet with the correct entries.
Example:
<servlet>
<servlet-name>TilesServlet</servlet-name>
<servlet-class>org.apache.struts.tiles.TilesServlet</servlet-class>
<init-param>
<param-name>definitions-config</param-name>
<param-value>/WEB-INF/tiles-defs.xml</param-value>
</init-param>
<init-param>
<param-name>definitions-parser-validate</param-name>
<param-value>true</param-value>
</init-param>
<load-on-startup>2</load-on-startup>
</servlet>
- Fujaba Tool Suite combines UML Class diagrams and UML Behaviour diagrams(Story Diagrams) to a powerful, easy to use, yet formal system design and specification language.
- Fujaba Tool Suite supports the generation of Java sourcecode out of the whole design which results in an executable prototype.
- Moreover the way back is provided, too (to some extend so far, not for productive use), so that Java sourcecode can be parsed and represented within UML.
- The Fujaba Tool Suite RE Edition is especially configured with plugins for Reverse Engineering and Design Pattern recognition.
Here is the sample structure of the Application:
formbeans: which stores the form data of the user
dto : The form we used for our business logic. It is recomonded to have no int etc. variables in form beans as it leads to conversion of user data which may fail if user enter wrong data. So we move this validation part to our dto's. All the fields of dto are clones of form beans except the return type.
mapper: these will map the form bean data to dto. We can use copyproperties() method of BeanUtils class to copy the data from form bean to dto.
actions: This package contains all the acction classes
dao: This package contains the Interfaces to invoke the backend data
dao-implementation: This package is the implementation of dao package.
service: This package is used to access the backend logic from our actions etc.
All jsp pages should go under some other directory either under root or WEB-INF.