Monday, December 28, 2015

Utilizing the JSF 2.3 f:convertDateTime Tag with the Java 8 Date-Time API

One of the features that is in-progress for the upcoming JSF 2.3 release is support for the Java 8 Date-Time API.  This support was added to the Mojarra 2.3.0 - Milestone 4 Snapshot before JavaOne 2015.  In this post, we'll take a brief look at this newly added support, which allows one to utilize the Java 8 Date-Time API with the standard JSF components via usage of the enhanced f:convertDateTime tag.  We will take a look at running an example application so that you can begin testing the features of JSF 2.3 today.

There are a number of posts covering the new f:convertDateTime functionality.  My fellow JSF 2.3 Expert Group member Arjan Tijms has an excellent post covering the new features of JSF 2.3:  http://arjan-tijms.omnifaces.org/p/jsf-23.html#1370  Anghel Leonard also has a repository with some great test sources:  https://github.com/AnghelLeonard/JSF-2.3/tree/master/JSF23convertDateTime.

In short, the f:convertDateTime tag now supports type attribute values that cover the Java 8 Date-Time data types.  Namely, you can now specify: both, date, time, localDate, localTime, localDateTime, offsetTime, offsetDateTime, and zonedDateTime.  You can then specify the pattern attribute on the tag to convert to the appropriate Date-Time format.

I have modified the sources for an application that I had written last year, AcmePools, such that it now supports the JSF 2.3 constructs when compiled and executed against Mojarra 2.3.0 - Milestone 4.  The updated sources have been posted to a new repository for JSF 2.3 testing purposes:  https://github.com/juneau001/AcmePools-JSF23. My post from 2014, Building and Testing JSF.next, has been updated to include details on utilizing the new Git repository for Mojarra.  It covers the basics of building Mojarra, and testing against the snapshot.  Please follow the directions in the post to get started.  Next, clone the new AcmePools sources that are compatible with JSF 2.3, and open the project in NetBeans, as shown in Figure 1.
Figure 1:  AcmePools-JSF23 in NetBeans

Once you've got the project open in NetBeans, you are ready to begin testing.  Take a look at the /job/List.xhtml view, and look at the "Job Date" column of the dataTable.  The h:outputText component has an f:convertDateTime tag applied to it, which will convert the date to the localDate type, as seen below.

<p:column>
         <f:facet name="header">
             <h:outputText value="Job Date"/>
         </f:facet>
         <h:outputText value="#{item.jobDate}">
              <f:convertDateTime type="localDate" pattern="MM/dd/yyyy"/>
         </h:outputText>
</p:column>


Taking a look at the jobDate field of the Jobs entity, you can see that it is of type LocalDate:

@Column(name = "JOB_DATE")
private LocalDate jobDate;

Similarly, if we look at the /job/Create.xhtml view, you can see that the standard inputText component can contain an embedded f:convertDateTime tag to perform the required input conversion.  In this case, we are using the PrimeFaces tag library, which also works with the f:convertDateTime tag.

<p:inputText id="jobDate" value="#{jobController.selected.jobDate}" title="Job Date">
     <f:convertDateTime type="localDate" pattern="MM/dd/yyyy"/>
</p:inputText>

Behind the scenes, this all works because of some changes made in the Mojarra javax.faces.convert.DateTimeFormatter class.  JSF 2.3 requires the use of Java 8, which enables the JSF developers to directly modify the sources to include Java 8 Date-Time classes.  As a quick test, I've modified the index.xhtml view of the application to include a Date-Time testing panel at the top.

<p:panel header="Date Test Panel">
    <p:inputText value="#{testController.todaysDate}">
        <f:convertDateTime type="localDate" pattern="dd-MM-yyyy"/>
    </p:inputText>
    <br/><br/>
    <h:outputText value="#{testController.todaysDate}">
        <f:convertDateTime type="localDate" dateStyle="short" />
    </h:outputText>
    <br/>
    <h:outputText value="#{testController.todaysDate}">
        <f:convertDateTime type="localDate" dateStyle="long"/>
    </h:outputText>
    <br/><br/>
    <h:outputText value="Today's Date is (old): #{testController.oldStyleDate}">
        <f:convertDateTime type="date"/>
    </h:outputText>
</p:panel>

The test panel looks like that in Figure 2.
Figure 2:  Date-Time Test Panel


Note that the AcmePools-JSF23 project can also be used to test other new JSF 2.3 features.  Download the sources, along with Mojarra 2.3.0 and get started testing JSF 2.3!

Tuesday, December 08, 2015

Jython - Mature, but Fresh!

The Jython team has been doing a lot of work over the years to maintain one of the most mature alternative languages for the JVM.  Jython is of course Python for the JVM, and the latest iteration of Jython is 2.7, which brings it ever closer to matching the complete functionality of the  C-based Python 1 for 1.  For instance, Jython 2.7 provides built in support for setuptools, which is an essential part of the Python ecosystem for installation of Python modules, and adds support for dictionary comprehensions.  It also provides more robust integration between Java and Python, so that Python modules can be used more easily from Java, and vice versa.

I had the pleasure of writing an article about the latest version of Jython recently with Jim Baker, one of the key Jython developers.  I've known Jim for a long time now, and it was great to have the opportunity to write an article with him, and his expertise really makes the article, as he delves into technical information behind Jython...giving key insight to how it works.  In the article, readers are provided with a brief introduction to Jython, then they are taken through some of the key features in Jython 2.7 via an example-driven explanation.  Readers learn how to work with Java libraries from Jython, how to install Python modules, and more.

I want to thank Oracle and Andrew Binstock for giving Jim and I the opportunity to write an article for the excellent Java Magazine.  I also want to thank Jim for taking the time to work on this article...it turned out excellent and it was great working with you.

You can read the article entitled "Jython 2.7: Integrating Python and Java" in the Nov/Dec 2015 issue of Java Magazine.

Thursday, October 01, 2015

CJUG Adopt-A-JSR - September 2015 Meetup

On Tuesday, September 29th, the Chicago Java User Group (CJUG) held its second online only session that focused on the Adopt-a-JSR initiative for Java and Java EE.  CJUG has formally adopted JSR 366 - Java Platform, Enterprise Edition 8 (Java EE 8) Specification, and the group has been partaking in the Adopt-a-JSR initiative by promoting information regarding the upcoming Java EE release, and specifically targeting the JSRs that are part of the all-encompassing JSR 366 umbrella.

During this latest session, we provided a brief overview of the current status for each of the JSRs that are part of Java EE 8, and we paid special attention to those that are already in-progress.  To the point, the following JSRs are currently in active movement:

JSR 365 - CDI 2.0
JSR 367 - JSON-B
JSR 368 - JMS 2.1
JSR 369 - Servlet 4.0
JSR 370 - JAX-RS 2.1
JSR 371 - MVC 1.0
JSR 372 - JSF 2.3
JSR 374 - JSON-P
...and most recently, there has been mention of Java Batch 1.1 getting started...

It is also worth mentioning that there are a number of other JSRs planned for inclusion with Java EE 8, but they've not had much activity, as yet.

While not each of these JSRs have active sources that are ready for testing, they have all made some progress either via mailing list discussion, or early specification drafts.  After providing the overview, we delved into a couple of the more active JSRs, including JSR 372:  JSF 2.3, and JSR 374:  JSON-P.  In doing so, we demonstrated how to check out the sources for these JSRs, add them to an IDE, such as NetBeans, and then perform a build and testing.  While we did not have enough time to get into any specific issues in detail, we also looked at the JIRA for JSR 374 and held short discussions on a few of the issues.

We then took a break from Java EE, and focused a bit on OpenJDK and the JDK 9 project.  Bob Paulin demonstrated how it is possible to pull down the JDK 9 sources and begin working with early builds of the modularity solution now.  During Bob's demonstration, he created a fully-functional modular program.  We also discussed the possibility of future CJUG involvement in the Adopt-a-JSR program for Java SE.

In summary, the September 2015 Adopt-a-JSR session was a great chance for us to provide a current status of the ongoing efforts towards Java EE 8, and it also gave us a chance to demonstrate what is currently possible with JDK 9.

If you are interested in listening to the audio from the Adopt-a-JSR session, please use the following link:  Audio for CJUG Adopt-a-JSR Sept 2015

We plan to hold more sessions online that focus on Adopt-a-JSR in the near future.  Please stay tuned for more...

Friday, June 05, 2015

Utilizing the Java 8 Date-Time API with JSF and Java EE 7

If you are using Java 8 with Java EE 7, then there may be some quirks that you run into when trying to utilize some of the Java 8 new features.  One such quirk is that the new Date-Time API does not work with many of the Java EE 7 APIs by default since they are built to work with java.util.Date and/or the older Date APIs.  However, this is not a road block, as there are many ways to work around such issues.  In this post, I will demonstrate how you can tweak your JSF application to allow use of the Java 8 Date-Time APIs along with JPA and date converters.

First things first, if you wish to persist dates using the new LocalDate class (or others that are part of the Java 8 Date-Time API), you need to develop a converter which will automatically convert from java.time.LocalDate to java.util.Date and vice versa in order to work with JPA 2.1.  This is easy enough to do, especially since there is no need to configure any XML to establish the converter.  The following code is a converter that is used to provide Java 8 Date-Time support for JPA:

import java.time.Instant;
import java.time.LocalDate;
import java.time.LocalDateTime;
import java.time.LocalTime;
import java.time.Month;
import java.time.ZoneId;
import java.util.Date;
import javax.persistence.AttributeConverter;
import javax.persistence.Converter;

/**
 * Converter to provide Java 8 Date/Time API Support to JPA
 * 
 * @author Juneau
 */
@Converter(autoApply = true)
public class LocalDatePersistenceConverter implements AttributeConverter<LocalDate, Date> {
    @Override
    public Date convertToDatabaseColumn(LocalDate entityValue) {
        LocalTime time = LocalTime.now();
        Instant instant = time.atDate(entityValue).atZone(ZoneId.systemDefault()).toInstant();
        return Date.from(instant);
    }

    @Override
    public LocalDate convertToEntityAttribute(Date databaseValue) {
        Instant instant = Instant.ofEpochMilli(databaseValue.getTime());
        return LocalDateTime.ofInstant(instant, ZoneId.systemDefault()).toLocalDate();
    }
}

Looking at the code, the convertToDatabaseColumn() method accepts a LocalDate from the entity, class and then utilizes some of the Java 8 Date-Time API utilities to convert it to a java.util.Date so that it can be stored into the database.  The second method, convertToEntityAttribute() takes a java.util.Date from JPA and converts it in the opposite direction into a LocalDate object for use with your Java 8 based application.  The @Converter annotation registers the class as a converter, and implementing AttributeConverter applies the converter to an entity class in order to convert the state to a database column and back again.

Next, if you attempt to apply a JSF converter to a Java 8 LocalDate within your application, say within a view, you will experience issues unless you write a special FacesConverter implementation to apply against the component that you wish to convert to the LocalDate.  Writing a FacesConverter is just as simple as the entity class attribute converter, and registration is as easy as applying an annotation to the converter.  The following class is an example of the FacesConverter that will convert a java.time.LocalDate to a java.util.Date for use within a JSF component.  Note:  This also works with popular JSF component libraries, such as PrimeFaces.

import java.time.LocalDate;
import java.time.format.DateTimeFormatter;
import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
import javax.faces.convert.FacesConverter;

/**
 * Faces converter for support of LocalDate
 * @author Juneau
 */
@FacesConverter(value="localDateTimeConverter")
public class LocalDateTimeConverter implements javax.faces.convert.Converter {

    @Override
    public Object getAsObject(FacesContext context, UIComponent component, String value) {
          return LocalDate.parse(value);
    }

    @Override
    public String getAsString(FacesContext context, UIComponent component, Object value) {

        LocalDate dateValue = (LocalDate) value;
        
        return dateValue.format(DateTimeFormatter.ofPattern("MM/dd/yyyy"));
    }
    
}
Now let's look at the code a bit.  This FacesConverter class is registered via the @FacesConverter annotation, and the class can simply implement the javax.faces.convert.Converter interface.  Next, take a look at the implementation.  The getAsObject() method is used to parse a String from the component and return it as a java.time.LocalDate, whereas the getAsString() method accepts a LocalDate object and returns it as a String in the specified date format.  This demonstrates another nice feature of Java 8...the DateTimeFormatter class, which makes it easy to format a java.time.* object.  

That's it...not too difficult to use the nice Java 8 Date-Time API within a Java EE 7 application.  Now let's apply the converter to a date component.  The following markup demonstrates how to apply the converter to a PrimeFaces calendar component.

<p:calendar id="enterDate" converter="localDateTimeConverter" style="width: 100%;"

  readonly="true" value="#{myExcellentJsfController.current.enterDate}">

  </p:calendar>

Wednesday, April 22, 2015

Getting Started with Jython 2.7 in NetBeans IDE 8.0.2

The Jython 2.7 release is on the horizon.  In fact, Jython 2.7 release candidates are available from the Jython site at the time of this writing.  For a list of the new features and repairs, please refer to the Git repository.

Whether you are a seasoned Python or Jython developer, or whether you are looking to learn a new language, the NetBeans IDE makes for an excellent tool to get going with Jython development.  The Python module is easy to install, and it allows one to create new Python/Jython projects from scratch, or create projects from existing sources.  For the most recent information on the NetBeans Python module, please refer to the online documentation at NetBeans.org.

To use Jython 2.7 with the NetBeans Python module.  You must first create a Python Platform within the IDE that points to your installation of Jython 2.7.  After you've successfully installed the Python module, go to the NetBeans "Tools" menu, and select "Python Platforms".  The Python Platform Manager dialog will open, allowing you to add one or more Python Platforms for use (Figure 1).

Figure 1:  NetBeans Python Platform Manager

To add Jython 2.7 as a platform, click on "New" and then traverse to the Jython installation bin directory, and then select the jython executable.  You can also manage your Python Path and Java Path from this dialog. 

NetBeans provides a great tool for working with Jython, as it allows for easy management of applications, Python eggs, testing, and debugging.


Saturday, February 21, 2015

RESTful Charts with JAX-RS and PrimeFaces

Oftentimes, it is useful to utilize a chart for providing a visual representation of your data. PrimeFaces supplies charting solutions that make it easy to add visual representations of your data into web and mobile applications. If we couple the use of PrimeFaces charting components with RESTful web service data, we can create custom charts that scale well for both desktop and mobile devices.

In this post, I will update the Java EE 7 Hands On Lab MoviePlex application to provide a dashboard into which we can integrate PrimeFaces chart components. We'll create one chart in this example, but you can utilize this post to help you build even more charts in a similar manner. Specifically, we will utilize a RESTful web service to glean movie theater capacity information, and we'll display each of the theater capacities using a PrimeFaces Bar Chart.

To begin, download the Java EE 7 Hands On Lab application solution archive, if you have not already done so.  From there, open it up within NetBeans IDE. To create this post, I am using NetBeans 8.0.2. Once the project has been imported into NetBeans, deploy it to your application server (GlassFish 4.1 in my case) by right-clicking on the project and choosing Run.  Once deployment is complete, open the theater web service within a browser by opening the following URL: http://localhost:8080/ExploringJavaEE7/webresources/theater/.  The web service should produce a listing that looks similar to that in Figure 1.
Figure 1:  Theater Web Service XML


We will utilize the data from this web service to feed our dashboard widget.  Let's first create the backend code, and then we will tackle the UI.  First, create a new package named org.glassfish.movieplex7.jsf, by right-clicking on Source Packages, and selecting "New..."-> "Java Packages".  Next, create a JSF Managed Bean controller by right-clicking on that package, and selecting "New..."-> "JSF Managed Bean", and name it DashboardController.   Let's annotate the controller as @SessionScoped, and then implement java.io.Serializable.  In this controller, we will obtain the data, and construct the model for the dashboard.  We will first query the web service utilizing a JAX-RS client, and we will utilize the data to populate list of Theater objects.  Therefore, we need to define the following four fields to begin:

Client jaxRsClient;
// Typically not hard coded...store in a properties file or database
String baseUri = "http://localhost:8080/ExploringJavaEE7/webresources/theater/";
    
private List<Theater> theaterList;
private BarChartModel theaterCapacityModel;

The Client is of type javax.ws.rs.client.Client, and we will initialize the field within the class constructor by calling upon the javax.ws.rs.client.ClientBuilder, as follows:

public DashboardController() {
    jaxRsClient = ClientBuilder.newClient();
}

Next up, we need to create a method to load the data, create, and configure the model.  In our controller, the init() method basically contains an implementation of delegating tasks to other methods. The init() method implementation invokes two methods: loadData(), and createTheaterCapacityModel().

public void init() {
    loadData();
  
    createTheaterCapacityModel();
}

The code is written such that it will be easy to add more widgets to our dashboard at a later date, if desired. The loadData() method provides the implementation for loading the data from our web service into our local list.


private void loadData() {
       
    theaterList = jaxRsClient.target(baseUri)
            .request("application/xml")
            .get(new GenericType>() {
            }
            );
      
}

If we had more widgets, then we would add the data loading code for those data models into this method as well. Next, we need to initialize the org.primefaces.model.chart.BarChartModel that we had defined, and load it with the data from the web service. The initTheaterCapacityModel() method contains the implementation for creating the BarChartModel, and populating it with one or more ChartSeries objects to build the data.

public BarChartModel initTheaterCapacityModel() {

    BarChartModel model = new BarChartModel();

    ChartSeries theaterCapacity = new ChartSeries();
    theaterCapacity.setLabel("Capacities");


    for (Theater theater : theaterList) {

        theaterCapacity.set(theater.getId(), theater.getCapacity());

    }
    model.addSeries(theaterCapacity);

    return model;
}

As you can see, this model consists of a single org.primefaces.model.chart.ChartSeries object.  Actually, the model can contain more than a single ChartSeries object, and different colored bars will be used to display that data within the chart.  In this case, we simply add the theater ID and the capacity for each Theater object to the ChartSeries object, and then we add that to the BarChartModel.


The createTheaterCapacityModel() method  is invoked within our init() method, and in it we call upon the initTheaterCapacityModel() method for creation of the org.primefaces.model.chart.BarChartModel, and then configure it accordingly.

private void createTheaterCapacityModel() {
    theaterCapacityModel = initTheaterCapacityModel();

    theaterCapacityModel.setTitle("Theater Capacity");
    theaterCapacityModel.setLegendPosition("ne");
    theaterCapacityModel.setBarPadding(3);
    theaterCapacityModel.setShadow(false);

    Axis xAxis = theaterCapacityModel.getAxis(AxisType.X);
    xAxis.setLabel("Theater");

    Axis yAxis = theaterCapacityModel.getAxis(AxisType.Y);
    yAxis.setLabel("Capacity");
    yAxis.setMin(0);
    yAxis.setMax(200);

}

As you can see, inside of the method, we initialize the model by calling upon initTheaterCapacityModel(), and then we configure it via a series of "set" methods. Specifically, we set the title, position, and provide some visual configurations. Next, set up the axis by calling upon the model's getAxis() method, and passing the X and Y axis constants. We then configure each axis to our liking by setting a label and min/max values for the Y axis.  See the full sources for the class at the end of this post.

That does it for the server-side code, now let's take a look at the UI code that is used to display the chart component. Begin by generating a new XHTML file at the root of the Web Pages folder in your project by right-clicking and choosing "New..."-> "XHTML...", and name the file dashboard.xhtml. The sources for dashboard.xhtml should contain the following:

<html xmlns:f="http://xmlns.jcp.org/jsf/core" xmlns:h="http://xmlns.jcp.org/jsf/html" xmlns:p="http://primefaces.org/ui" xmlns="http://www.w3.org/1999/xhtml">
    <h:head>
     
     
        <title>Theater Dashboard</title>

    </h:head>

    <h:body>
        <f:event listener="#{dashboardController.initView}" type="preRenderView"/>
        <h:form id="theaterDash" prependid="false">
            <p:growl id="growl" showdetail="true"/>
            <p:layout fullpage="true">
                <p:layoutUnit position="center">
                   
                            <p:panel header="Capacity for Theaters" id="theater_capacity" style="border: 0px;">
                                <p:chart model="#{dashboardController.theaterCapacityModel}" style="border: 0px; height: 200px; width: 500px;" type="bar">
                            </p:chart></p:panel>
                         
                 
                </p:layoutUnit>
            </p:layout>

            <p:poll interval="60" listener="#{dashboardController.pollData}"/>


        </h:form>


    </h:body>

</html>



Fairly simplistic, the JSF view contains a PrimeFaces layout, including a panel and a chart.  Near the top of the view, an f:event tag is used to invoke the listener method which is implemented within the DashboardController class, identified by initView().  For the purposes of this example, the p:chart tag is where the magic happens. The chart type in this case is set to "bar", although other options are available (visit http://www.primefaces.org/showcase). The model is set to                         #{dashboardController.theaterCapacityModel}, which we defined, populated, and configured within the controller class. We then provide a width and a height to make the chart display nicely.  In case the data changes (I know theaters do not increase or decrease in size often, but go with me here), we added a PrimeFaces poll component invoke the pollData() method, which refreshes the data periodically.  In this case, the data will be refreshed every 60 seconds.

When complete, the chart should look like that in Figure 2.


Figure 2:  The PrimeFaces Bar Chart

The chart is interactive, and if you click on the label, the bars will become hidden.  This is handy if you have more than one category (via the ChartSeries).  You can even include a p:ajax tag within the chart component, and invoke an action when the chart is clicked on...perhaps a dialog will pop up to display some additional data on the item which is clicked.

That does it...now you can create even more charts utilizing PrimeFaces and RESTful web services.  I suggest building upon the MoviePlex application to see what other possibilities can be had.

Full Sources for the DashboardController class:

package org.glassfish.movieplex7.jsf;

import java.util.List;
import javax.inject.Named;
import javax.enterprise.context.SessionScoped;
import javax.faces.component.UIComponent;
import javax.faces.component.UIViewRoot;
import javax.faces.context.FacesContext;
import javax.ws.rs.client.Client;
import javax.ws.rs.client.ClientBuilder;
import javax.ws.rs.core.GenericType;
import org.glassfish.movieplex7.entities.Theater;

import org.primefaces.model.chart.Axis;
import org.primefaces.model.chart.AxisType;
import org.primefaces.model.chart.BarChartModel;
import org.primefaces.model.chart.ChartSeries;

/**
 *
 * @author Juneau
 */
@Named(value = "dashboardController")
@SessionScoped
public class DashboardController implements java.io.Serializable {
    
    Client jaxRsClient;
    // Typically not hard coded...store in a properties file or database
    String baseUri = "http://localhost:8080/ExploringJavaEE7/webresources/theater/";
    
    private List theaterList;
  
    private BarChartModel theaterCapacityModel;


    /**
     * Creates a new instance of FamisEquipPmChartController
     */
    public DashboardController() {
        jaxRsClient = ClientBuilder.newClient();
    }
    
    public void init() {
        loadData();

        createTheaterCapacityModel();
    }
    
    /**
     * Initializes the view on page render...if we wish to grab a reference
     * to a panel, etc.
     */
    public void initView(){
        UIViewRoot viewRoot =  FacesContext.getCurrentInstance().getViewRoot();
        // Do something
    }

    public void pollData() {
        System.out.println("polling data...");
        loadData();
    }

    /**
     * JAX-RS client to poll the data
     */
    private void loadData() {
       
        theaterList = jaxRsClient.target(baseUri)
                .request("application/xml")
                .get(new GenericType>() {
                }
                );
      
    }

    

    /**
     * Initialize the Bar Chart Model for Displaying PM Estimated Hours by Month
     *
     * @return
     */
    public BarChartModel initTheaterCapacityModel() {

        BarChartModel model = new BarChartModel();

        ChartSeries theaterCapacity = new ChartSeries();
        theaterCapacity.setLabel("Capacities");


        for (Theater theater : theaterList) {

            theaterCapacity.set(theater.getId(), theater.getCapacity());

        }
        model.addSeries(theaterCapacity);

        return model;
    }

   

 
    
    private void createTheaterCapacityModel() {
        theaterCapacityModel = initTheaterCapacityModel();

        theaterCapacityModel.setTitle("Theater Capacity");
        theaterCapacityModel.setLegendPosition("ne");
        theaterCapacityModel.setBarPadding(3);
        theaterCapacityModel.setShadow(false);

        Axis xAxis = theaterCapacityModel.getAxis(AxisType.X);
        xAxis.setLabel("Theater");

        Axis yAxis = theaterCapacityModel.getAxis(AxisType.Y);
        yAxis.setLabel("Capacity");
        yAxis.setMin(0);
        yAxis.setMax(200);

    }

    /**
     * @return the theaterCapacityModel
     */
    public BarChartModel getTheaterCapacityModel() {
        return theaterCapacityModel;
    }

    /**
     * @param theaterCapacityModel the theaterCapacityModel to set
     */
   public void setTheaterCapacityModel(BarChartModel theaterCapacityModel) {
        this.theaterCapacityModel = theaterCapacityModel;
    }
    
   
}

Wednesday, February 11, 2015

JSF Tip: Utilizing Expression Language to Create Cross Platform File Links

Does your organization contain a multi-platform environment?  If so, then you may have the requirement to add links to file shares within your Java EE application, and those links may require use of a different protocol depending upon platform of the user's machine.  For instance, in an organization that contains both Windows and OS X, a network file share may require use of NFS (file://) prefix from a Windows machine, and use of SMB (smb://) prefix from an OS X machine. How can you easily distinguish which link to provide to your users within a web application?

There are many solutions to this problem.  Some solutions involve use of a servlet to determine the user's operating system, or some other solution that requires use of server-side code.  In this tip, I'll show you how to determine the user's operating system via the request object from Expression Language.

To determine whether a user requires the use of NFS or SMB for accessing a file share, simply use expression language to obtain the user-agent from the request object as such:

#{header['user-agent'].contains('Windows')?'file://':'smb://'}rest/of/url/here

In the EL above, if the user-agent contains "Windows", then the
file://
prefix is used, otherwise
smb://
will be utilized for the link. This solution can be implemented directly within the views, relieving the requirement to recompile code.