Skip to main content

Welcome to Geoff Hayward's Weblog

Commenting on Java, JavaFX, Java EE, Joomla, and IoT.

JSF's h:outputStylesheet and h:outputScript elements have an odd way of ordering linked resources. For example if you do not set the target element of an h:outputScript to body the JavaScript is output before the CSS. This is irrespective of the order given in a template.

I needed to put an <!--[if lte IE 7]> [...] <![endif]--> element into a template. OmniFaces' o:conditionalComment is a great element for this; but the <!--[if lte IE 7]> [...] <![endif]--> condition was being output before the main CSS.

To fix this resource loading problem use a plain old HTML link elements instead of JSF h:outputStylesheet elements. Use this element with the HTML link elements having #{resource['libs:reset.css']} as there href.

<link rel="stylesheet" href="#{resource['libs:reset.css']}" />
<link rel="stylesheet" href="#{resource['css:login.css']}" />
<o:conditionalComment if="lte IE 7" >
     <link rel="stylesheet" href="#{resource['css:login-ie7.css']}" />
</o:conditionalComment>

Will then output:

<link rel="stylesheet" href="/javax.faces.resource/reset.css?ln=libs" />
<link rel="stylesheet" href="/javax.faces.resource/login.css?ln=css" />
<!--[if lte IE 7]>
     <link rel="stylesheet" href="/javax.faces.resource/login-ie7.css?ln=css" />
<![endif]-->

Which is the desired resource ordering.


Tags: JSFOmniFaces

Read

Sometimes JSF does not have a component that will produce a particular type of HTML element. That's not a problem but, I always forget the three method deep route to the context path. I always find I have to work through an IDE's code completion tool to find the application's path.

Here it is for next time:

#{facesContext.externalContext.requestContextPath}

A shorter version:

#{request.contextPath}

Just for completeness here is the JSP version:

${pageContext.request.contextPath}

And finaly, the scriptlet version:

<%
    String root = pageContext.getRequest().getServletContext().getContextPath();
%>

If you know any more please do leave a comment.


Tags: JSFJSP

Read

JSF Facelets can store the returned value yielded from a call to an EJB. Doing so will mean the EJB does less work.

Let's say you are implementing a Facelet that will display a message stating something like 'No results' when a collection is empty. If the collection is not empty, the Facelet will call the EJB a second time. First to calculate the size of the collection; second to display the data in the collection etc.

Here is an example:

    [...]

    <ui:fragment rendered="#{pages.all().size() == 0}" >
        <h:outputText value="No pages yet." />
    </ui:fragment>
                
    <ui:fragment rendered="#{pages.all().size() > 0}" >
        <h:dataTable value="#{pages.all()}" var="page">
            [...]
        </h:dataTable>
    </ui:fragment>

    [...]

In the example above the Facelet calls the EJB three times. First to calculate the size of the collection; second to display the elements the data table will occupy; third the data from the collection.

How to Store Values in JSF Facelets

The calling to the EJB can be reduced to just once per page render. Calling the backing bean using the ui:param JSF element will store the returned value in a variable.

<f:metadata>
   <ui:param name="pageSet" value="#{pages.all()}" />
</f:metadata>

Using the ui:param JSF element, here is an improved example:

    [...]

    <f:metadata>
      <ui:param name="pageSet" value="#{pages.all()}" />
    </f:metadata>

    [...]

    <ui:fragment rendered="#{pageSet.size() == 0}" >
        <h:outputText value="No pages yet." />
    </ui:fragment>
                
    <ui:fragment rendered="#{pageSet.size() > 0}" >
        <h:dataTable value="#{pageSet}" var="page">
            [...]
        </h:dataTable>
    </ui:fragment>

    [...]

I hope this helps.



Read

I have been trying to put an older embedded Jetty served application onto Java 8. The application's JSP files where, however, not compiling. This delayed having the benefits Java 8 brings to development.

After a lot of digging I discovered that the Mavan 'org.mortbay.jetty' namespace (a.k.a. groupid) had been superseded by 'org.eclipse.jetty'. The newer development and fixes by the Jetty project are in the later namespace. Therefore, by replacing the old 'org.mortbay.jetty' dependency:

<dependency>
    <groupId>org.mortbay.jetty</groupId>
    <artifactId>jsp-2.1-glassfish</artifactId>
  <version>9.1.02.B04.p0</version>
</dependency>

with the new 'org.eclipse.jetty'. dependency:

<dependency>
  <groupId>org.eclipse.jetty</groupId>
    <artifactId>jetty-jsp</artifactId>
  <version>9.3.0.M1</version>
</dependency>

the JSP's compile and the older project now works with Java 8.



Read

Here are the photos I took at Devoxx Poland Java conference this year.

 



Read

Mailing List


Responsive Media

With the ResponsiveMedia plugin for Joomla it is easy to add 3rd party content from YouTube, Vimeo, and Instagram right in to any Joomla! article.

ResponsiveMedia