In SAP Web Channel Experience Management (WCEM) a decision was taken to use Java Server Faces (JSF) as UI technology. In this blog I'll show the arguments behind this decision and try to provide a short comparison between the Java Server Pages (JSP) as used UI technology in Internet Sales and JSF.
After several years investment in JSP technology we saw that although JSP has made a great leap forward compared to Servlet-based rendering, more complex business processes (and based on that more complex UIs) lead to troublesome JSP structures. Even if the JSP tag technology allows Java code abstraction, sooner or later Java code will be integrated directly onto the JSP pages again. Any problem analysis there will turn into a nightmare because debugging of the JSPs directly or the generated Servlets is a complex and often poorly supported task. In JSF, especially when using the Facelet technology, there is no Java code on XHTML pages, which are parsed from JSF. This makes JSF generated HTML code more transparent and clear.
Taking closer look at the UI components in JSF we see that not only clear HTML rendering process has been established. Recurring tasks like Data Binding (save request data in in the corresponding object), conversion, validation are integrated into the JSF life cycle by well-defined interfaces which can be implemented uniquely dependent on the processed business logic. JSP gives not such strong answer for these questions so that individual code is needed or other frameworks will be integrated additionally.
Futuremore, with the introduced UI compositions in JSF the separation of UI structures is much better possible. By this it is possible to implement layouts which can be reused for many pages. Based on the standard JSF composition framework even dynamic exchange of page contents is feasible and leads to very flexible structures.
As we started to design the new framework for the SAP Web Channel Experience Management solution we were faced with the situation that the JSF 2 specification was already in an advanced stage, but unfortunately it wasn't released and thus the implementation in Java community wasn't finally available yet. Because of that we had to find a way to provide a satisfied solution for the WCEM 1.0 release but at the same time foresee a technical way how a switch to JSF 2 could be possible in one of the future WCEM releases.
Already in the WCEM 2.0 development time frame a stable JSF 2.1 implementation was available so that we could do such switch. With this step we focused on reuse of standard JSF 2.1 features so that we could replace lot of special implementations by standard JSF 2.1 functionality. For example we adopted the Composite Components, AJAX support and bookmark support.
Additionally, because JSF 2.1 provides much better extensibility concepts, we could close many gaps simply by using the available extension points so that the WCEM 2.0 implementation could be realized compatibly with the JSF standard. This allows for example usage of other 3rd party components in custom projects. Due to the modification free extensions, future adaptations of new JSF frameworks should be less complex as well.
As already mentioned, some features aren't available in standard JSF 2.1 so that the following extensions were incorporated in the WCEM framework:
- Besides the standard UI Components SAP implemented additionally more complex UI elements like Breadcrumbs, Data Grids, Calendar Control, etc.
- For the HTML and JS code rendering the Velocity Template Engine is used. This generates code from plain text template files and by this allows to change the generated HTML without code in Java. So you do not need a Java development environment. The compile and deploy cycle becomes obsolete.
- Extendible and customizable UI Themes support ease and flexible CSS implementations.
- Based on JSF standard Composite Components so called View Components were introduced which enrich Composite Components with a View Component Handler. The View Component Handler acts like a backing bean for the view by hosting controller logic and providing separation from the Business Object logic. Additionally this concept allows better reuse of views like generic UI
fragments on different pages.
Of course several other features are available in the WCEM framework but to mention them all in this blog would go beyond the scope of this blog. For more details I recommend to read the WCEM Development and Extension Guide available on http://help.sap.com/wec
Further details:
