Understanding Backing Files
The portal you created in A Simple Example of Establishing IPC uses backing files to achieve communication between two portlets. Backing files allow you to programatically add functionality to a portlet by implementing (or extending) a Java class, which enables preprocessing (for example, authentication) prior to rendering the portal controls.
What are Backing Files?
Backing files are simple Java classes that implement the com.bea.netuix.servlets.controls.content.backing.JspBacking
Which Controls Support Backing Files?
At this time, the following controls support backing files:
- Desktops
- Books
- Pages
- Portlets
How Backing Files are Executed
All backing files are executed before and after the JSP is called. In its lifecycle, each backing file calls these methods:
init()
handlePostBackData()
preRender()
dispose()
On every request, the following occurs:
- All
init() methods are called on all backing files on an "in order" basis (that is, in the order they appear in the control tree; for more information on the control tree and its lifecycle please see Controls in the white paper). This method gets called whether or not the control (that is, portal, page, book, or desktop) is on an active page.
- Next, if the operation is a postback and the control (a portlet, page, or book) is on a visible page, all
handlePostbackData() methods are called. In other words if portlet is on a page but its parent page is not active, then this method will not get called.
- If
_nfpb="true" is set in the request parameter of any handlePostbackData() methods called, raiseChangeEvents() is called. This method causes events to fire.
- Next, all
preRender() methods are called for all controls on an active (visible) page.
- Next, the JSPs get called and are rendered on the active page by the
<render:beginRender> JSP tag. Rendering is stopped with the <render:endRender> tag.
- Finally, the
dispose() method gets called on the backing file.
Thread Safety with Backing Files
A new instance of a backing file is created per request, so you don't have to worry about thread safety issues. New Java VMs are specially tuned for short-lived objects, so this is not the performance issues it once was in the past. Also, JspContent controls support a special type of backing file that allows you to specify whether or not the backing file is thread safe. If this value is set to true, only one instance of the backing file is created and shared across all requests.
<?xml version="1.0" encoding="UTF-8"?>
<portal:root xmlns:netuix="http://www.bea.com/servers/netuix/xsd/controls/netuix/1.0.0"
xmlns:portal="http://www.bea.com/servers/netuix/xsd/portal/support/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/servers/netuix/xsd/portal/support/1.0.0 portal-support-1_0_0.xsd">
<netuix:portlet backingFile="backing.Listening" definitionLabel="portlet_5" title="bPortlet">
<netuix:handlePortalEvent event="onMinimize" eventLabel="handlePortalEvent1"
filterable="true" fromSelfInstanceOnly="false" onlyIfDisplayed="true" sourceDefinitionLabels="portlet_4">
<netuix:invokeBackingFileMethod method="handlePortalEvent"/>
</netuix:handlePortalEvent>
<netuix:titlebar>
<netuix:maximize/>
<netuix:minimize/>
<netuix:delete/>
</netuix:titlebar>
<netuix:content>
<netuix:jspContent contentUri="/bPortlet.jsp"/>
</netuix:content>
</netuix:portlet>
</portal:root>
<A class=bea-portal-button
href="http://localhost:7001/JSR168PortalWebProject/appmanager/jsr168portal/desktop1?_nfpb=true&_windowLabel=T6011&_mode=edit&_pageLabel=P2001">Edit
</A>