Each JSF view is backed by a ViewScoped or RequestScoped backing bean. That backing bean accesses (by means of the ManagedProperty annotation) a session-scoped JSF-managed bean. The session-scoped JSF-managed bean then injects (by means of an @EJB annotation) a stateful EJB3 bean. This stateful EJB3 bean then injects an EntityManager with an extended persistence context (to avoid detachment of the web layer). We call that stateful EJB3 bean the service. The service actually is a DAO and handles all communication with the database through the single injected EntityManager (whether for one or more than one tables).

The basic motivation for this pattern (apart from the extended transaction context which was done to avoid detachment in the web layer), is that when separate different EntityManagers are injected in the various facades the problem arises that these EntityManagers are in fact different and keep different caches, also, an object created on one EntityManager cannot be merged in a second (again due to the multiple independent EntityManagers that have been injected).

There are two variations of the above pattern solely for organizational purposes:

1. one is to group the various table-specific methods and their implementations in facade-like DAO POJOs. The service EJB3 bean then simply contains dispatchers that rely to the implementations. The only benefit that that brings is to avoid having all the implementations in the same place.
2. a more radical variation is to actually implement the various table DAO facades as proper, stateful EJB3 beans and have them injected in the service EJB3 bean. In this patter, the service EJB3 bean acts simply as a place to inject all other EJB3 facades. The JSF-backing beans call a getFacade() method whose implementation ultimately relays to the service EJB3 bean before then can get the actual facades. This only works because, for some magical reason, we noticed that in this case the underlying, delegate, EntityManager object for all facades injected in the service EJB3 bean are the same. Therefore it is a more elegent variation than the variation above but it is also more magical and less clearly understood. It is more elegant because we no longer have to implement relaying methods in the EJB3 service bean and there exist actual DAO facades for all the various tables.

Contents:

Index: Orders-war/web/WEB-INF/web.xml
===================================================================
--- Orders-war/web/WEB-INF/web.xml	(revision 62)
+++ Orders-war/web/WEB-INF/web.xml	(working copy)
@@ -9,6 +9,10 @@
        primefaces.THEME
        #{themeSwitcherBean.current}
     
+    
       +        javax.faces.STATE_SAVING_METHOD
       +        client
       +    
     
       /index.xhtml
     

      

Examine constructs focusSurname, p:ajax event="keyup" and script.

Another way is to hardcode in the script definition in the .xhtml page access to the backing-beans properties using EL and at runtime, these are replaced by the actual values in the client-side code.

<C:Choose> >call on a backingBean method to select case at runtime<
[case 1: default]
... automatically generated ..
[case 2: hook for programmer]
inclusion of an external xhtml file which
is the one that the programmer modifies
</C:Choose>
          

<context-param>

<param-name>javax.faces.STATE_SAVING_METHOD</param-name>

<param-value>client</param-value>

</context-param>

<context-param>

<param-name>com.sun.faces.compressViewState</param-name>

<param-value>true</param-value>

</context-param>

• Get all users
• Cache Area