Details
Description
ICEmobile makes use of both JSP tags and JSF components. For efficient development, it is important to re-use code between these as much as possible, but it is also important to benefit from simplifications in each of these environments (for instance, developing an ICEmobile component should be no more difficult than developing a typical JSF component).
It appears that the JSF API would provide a useful abstraction layer even in the JSP case. Originally, the goal was to develop a pure JSP codebase that did not depend on JSF, but the requirement to support JSF will always exist for ICEmobile.
For instance, FacesContext and ResponseWriter could both be used by JSP tags if the FacesContext was initialized by a Servlet Filter. Certain JSF abstractions such as EL specifics and lifecycle Phase would simply be avoided.
The main drawback would be the requirement to include javax.faces.jar in the web application, but this situation would already occur for a combined JSF/JSP application.
It appears that the JSF API would provide a useful abstraction layer even in the JSP case. Originally, the goal was to develop a pure JSP codebase that did not depend on JSF, but the requirement to support JSF will always exist for ICEmobile.
For instance, FacesContext and ResponseWriter could both be used by JSP tags if the FacesContext was initialized by a Servlet Filter. Certain JSF abstractions such as EL specifics and lifecycle Phase would simply be avoided.
The main drawback would be the requirement to include javax.faces.jar in the web application, but this situation would already occur for a combined JSF/JSP application.
The FakeFacesFilter was used in both JSF and JSP applications. In the case of JSF, the FacesServlet replaced the stubbed out FakeFacesContext with the actual FacesContext used by JSF. In the case of JSP, the FakeFacesContext was accessible from the bean via FacesContext.getCurrentInstance().