I ran across an interesting post on the Oracle Technology Network forums the other day – a user asked a question about navigation within a portlet for deployment within a WebCenter application. I asked a few questions and the original poster responded with more detail.
You can read the original post here.
The basic problem the original poster is having: confusing “JSR 286″ (or even “JSR 168″) portlet development with Java Server Faces (JSF) development. (You can read about some basic JSR 168 portlet development here.) The important difference: knowing what is controlling the application flow of your portlet. In the JDeveloper way of developing standards-based portlets, the main point of entry and navigation is through JSP pages and associated action. If you are creating a Java Server Faces application, the main point of entry and navigation is through the FacesServlet. The navigation files (faces-config.xml) is a configuration of the FacesServlet.
Thus, it’s important that your JSF-developed portlet is controlled by FacesServlet, otherwise portlet navigation won’t work. Fortunately, Oracle provides a few handy tools to help you create portlets from JSF applications using the “JSF Portlet Bridge”. (The concept is also proposed to the Java Community Process through JSR 301 - so Apache MyFaces and others implements some of the same techniques.)
So in response to the forum post, I’m going to walk through a JDeveloper-based method for transforming a JSF Application into a portlet.
First, let’s take a look at a simple JSF application: one that simply allows a user to navigate back and forth between pages in the application:
The design of the pages is fairly simple as well: just a button that allows you to navigate (using an Application Action) to a second page.
The second page:
The application is controlled by the faces-config.xml file that all JSF applications use to configure the FacesServlet. To transform this application into a WebCenter deployable portlet, we’ll use JDeveloper to create the needed portlet files for us.
1) Transform the faces-config.xml file into an ADF Task Flow
Strictly speaking, we could also choose to create portlet entries from JSF pages, but ADF Task Flows offer us more flexibility in deployment. If you were designing your portlet from scratch, you might choose to start with ADF from the beginning. In our case, however, we can right-click on the faces-config.xml file within JDeveloper to Generate an ADF Task Flow.
You’ll be prompted by a wizard to name the task flow, etc. In this example, I’ve named the Task Flow “portlet-nav-taskflow”. (Subtracting points for creativity…)
Once the task flow is created, right-click your new taskflow to create a Portlet Entry – what we need to insert into “portlet.xml” that will tell a portlet container how to handle our application.
… and that’s it! We can now package the application for deployment on a Portlet Container (perhaps a WebCenter portlet producer), but to test deployment locally, we can right click on the portlet.xml file and select “run”. This will deploy our new portlet to a local container – particularly helpful if we’re developing the portlet side-by-side with a WebCenter Portal application. If the portlet runs successfully, you’re presented with a test page:
In summary, the challenge in creating new portlets is to keep in mind the technology that you are using to create the portlet – it can vary, but it does help to be consistent.