1. pattern for JSF / EJB3 with extended transaction context
  2. The following is a pattern that seems to avoid detached contexts and other JPA-problems.

    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.
  3. JSF client-side state management
  4. Original file = here

    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
         
    
          
  5. backing-bean / JavaScript communication
  6. The way to implement backing bean / JavaScript communication is demonstrated in this view and backing bean pair.

    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.

  7. extending xhtml views
  8. Using the:<C:Choose> tag it is possible to customize and extend an automatically generated xhtml view by introducing your own parts. The pattern is (refer to the html source for proper formatting cause I don't have the time to format it for html right now):
    <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>
              
    The benefit of the above pattern is that the totality of the xhtml view can be overwritten every time it is re-generated and the programmer will only modify the external (imported) xhtml file and will also overwrite the backing-bean's selector method to select case 2. NRL has an optinal annotation that allows that kind of code to be generated for a particular component, otherwise no extension facility is emmited (so if a programmer is not satisfied with the default emmission he has to modify the NRL and re-generate so that the extension facility is emmited).
  9. modal pop-ups in JSF and Ajax
  10. The modality of pop-ups in JSF can be arranged by virtue of a 'modal' property. However, there appears to be a bug and one has to also specify 'process=this'. This is strange as in the normal case of a modal dialog prompting for a 'yes'/'no' answer, the 'this' doesn't carry any data to the server side. I.e. the post only indicates (presumably) the actionListener to be called but it doesn't update any fields in the backing bean.
  11. ViewStateExpiredException and JSF saving state
  12. ViewStateExpiredExceptions can be alleviated with the use of JSF client-side state saving.
  13. state saving methods and compression
  14. In Mojarra (circa 2012) either used state saving to 'server', or, if set to client, disable compression, i.e. do a:

    <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>

  15. difference between 'rendered' and 'visible'
  16. rendered is server-side whereas visible is client-side.
  17. how to include the root context in an href
  18. There are at least two ways (view source if you can't see this):