Sunday Jun 24, 2012

Making Those PanelBoxes Behave

I have a little problem to solve earlier this week - misbehaving <af:panelBox> components... What do I mean by that? Well here's the scenario, I have a page fragment containing a set of panelBoxes arranged vertically. As it happens, they are stamped out in a loop but that does not really matter. What I want to be able to do is to provide the user with a simple UI to close and open all of the panelBoxes in concert. This could also apply to showDetailHeader and similar items with a disclosed attrubute, but in this case it's good old panelBoxes. 

Ok, so the basic solution to this should be self evident. I can set up a suitable scoped managed bean that the panelBoxes all refer to for their disclosed attribute state. Then the open all / close commandButtons in the UI can simply set the state of that bean for all the panelBoxes to pick up via EL on their disclosed attribute. Sound OK? Well that works basically without a hitch, but turns out that there is a slight problem and this is where the framework is attempting to be a little too helpful. The issue is that is the user manually discloses or hides a panelBox then that will override the value that the EL is setting. So for example.

  1. I start the page with all panelBoxes collapsed, all set by the EL state I'm storing on the session
  2. I manually disclose panelBox no 1.
  3. I press the Expand All button - all works as you would hope and all the panelBoxes are now disclosed, including of course panelBox 1 which I just expanded manually.
  4. Finally I press the Collapse All button and everything collapses except that first panelBox that I manually disclosed. 
The problem is that the component remembers this manual disclosure and that overrides the value provided by the expression. If I change the viewId (navigate away and back) then the panelBox will start to behave again, until of course I touch it again! Now, the more astute amoungst you would think (as I did) Ah, sound like the MDS personalizaton stuff is getting in the way and the solution should simply be to set the dontPersist attribute to disclosed | ALL. Alas this does not fix the issue. 

After a little noodling on the best way to approach this I came up with a solution that works well, although if you think of an alternative way do let me know. The principle is simple. In the disclosureListener for the panelBox I take a note of the clientID of the panelBox component that has been touched by the user along with the state. This all gets stored in a Map of Booleans in ViewScope which is keyed by clientID and stores the current disclosed state in the Boolean value. 

The listener looks like this (it's held in a request scope backing bean for the page):

public void handlePBDisclosureEvent(DisclosureEvent disclosureEvent) {
  String clientId = disclosureEvent.getComponent().getClientId(FacesContext.getCurrentInstance());
  boolean state = disclosureEvent.isExpanded();
  pbState.addTouchedPanelBox(clientId, state);

The pbState variable referenced here is a reference to the bean which will hold the state of the panelBoxes that lives in viewScope (recall that everything is re-set when the viewid is changed so keeping this in viewScope is just fine and cleans things up automatically). The addTouchedPanelBox() method looks like this:

public void addTouchedPanelBox(String clientId, boolean state) {
  //create the cache if needed this is just a Map<String,Boolean>
  if (_touchedPanelBoxState == null) {
    _touchedPanelBoxState = new HashMap<String, Boolean>();
  // Simply put / replace
  _touchedPanelBoxState.put(clientId, state);

So that's the first part, we now have a record of every panelBox that the user has touched. So what do we do when the Collapse All or Expand All buttons are pressed? Here we do some JavaScript magic. Basically for each clientID that we have stored away, we issue a client side disclosure event from JavaScript - just as if the user had gone back and changed it manually.

So here's the Collapse All button action:

public String CloseAllAction() {
  submitDiscloseOverride(pbState.getTouchedClientIds(true), false);
  return null;

The _uiManager.closeAllBoxes() method is just manipulating the master-state that all of the panelBoxes are bound to using EL. The interesting bit though is the line: 

submitDiscloseOverride(pbState.getTouchedClientIds(true), false);

To break that down, the first part is a call to that viewScoped state holder to ask for a list of clientIDs that need to be "tweaked":

public String getTouchedClientIds(boolean targetState) {
  StringBuilder sb = new StringBuilder();
  if (_touchedPanelBoxState != null && _touchedPanelBoxState.size() > 0) {
    for (Map.Entry<String, Boolean> entry : _touchedPanelBoxState.entrySet()) {
      if (entry.getValue() == targetState) {
        if (sb.length() > 0) {
  return sb.toString();

You'll notice that this method only processes those panelBoxes that will be in the wrong state and returns those as a comma separated list.

This is then processed by the submitDiscloseOverride() method:

private void submitDiscloseOverride(String clientIdList, boolean targetDisclosureState) {
  if (clientIdList != null && clientIdList.length() > 0) {
    FacesContext fctx = FacesContext.getCurrentInstance();
    StringBuilder script = new StringBuilder();
    Service.getRenderKitService(fctx, ExtendedRenderKitService.class).addScript(fctx, script.toString());

This method constructs a JavaScript command to call a routine called overrideDiscloseHandler() in a script attached to the page (using the standard <af:resource> tag). That method parses out the list of clientIDs and sends the correct message to each one:

function overrideDiscloseHandler(clientIdList, newState) {
  AdfLogger.LOGGER.logMessage(AdfLogger.INFO, "Disclosure Hander newState " + newState + " Called with: " + clientIdList);
  //Parse out the list of clientIds
  var clientIdArray = clientIdList.split(',');
  for (var i = 0; i < clientIdArray.length; i++){
    var panelBox = flipPanel = AdfPage.PAGE.findComponentByAbsoluteId(clientIdArray[i]);
    if (panelBox.getComponentType() == "oracle.adf.RichPanelBox"){
      panelBox.broadcast(new AdfDisclosureEvent(panelBox, newState));

So there you go. You can see how, with a few tweaks the same code could be used for other components with disclosure that might suffer from the same problem, although I'd point out that the behavior I'm working around here us usually desirable.

You can download the running example ( from here

Wednesday May 16, 2012

Placeholder Watermarks with ADF 11.1.2

I'm sure you're all familiar with the concept of watermarking an input field to provide the user with a greyed out hint as to what to do with it.  This is often used in search boxes or UIs where space is at a premium and you really don't have room for a label. Here's a small screenshot that shows what I mean:

Image of watermark in use

As you can see,  both the filter field and multi-line field have such text.  As soon as the user starts to enter values in these fields the watermark will disappear only to reappear if the user clears out the field.  In the past, there have been various JavaScript based solutions to this, but the HTML5 spec introduces a common way of doing this using an attribute on the <input> element called placeholder. Alas, only Chrome and FireFox have implemented this in their later versions, although it's on the list for IE 10. 

Now I probably won't be giving too much away if I let slip that placeholder support might possibly be standard in a future version of ADF Faces, but for now, I'm working in, so here's a simple implementation in the form of a custom JSF clientBehavior that will do it. 

For this, I actually took inspiration from a recent blog posting from Donatas Valys: Set Initial Focus component for Oracle ADF Faces.  He hit upon the smart idea of using a client behavior to mark a particular component as having initial focus, I've used essentially the same technique here, although extended a little bit because of the nature of the job I'm doing.

Create your Tag Library

So the first step will to create the tag (it will be called <afg:setWatermarkBehavior>) in your project.  Just select New > Web Tier > JSF/Facelets > Facelets Tag Library.  On the first page of the creation wizard, choose Deployable or Project Based, the choice is yours. For convenience I chose Project Based, then on Step 2 provide a file name and a namespace. I used adfglitz.taglib.xml and respectively, choose suitable values for your implementation. This step will do everything to register the Tag Library with the project (you'll see an entry is added to web.xml) 

Define the Behavior Definition 

Now you can edit the tag file and add the new behavior (or as I would have it "behaviour"). The taglib editor provides an overview view to make this simple:

Tag Lib editor

The important things to note here are:

  • The namespace (, we'll need that when adding this tag to the page. 
  • The name of the behavior tag - setWatermarkBehavior
  • The ID of the behavior tag - oracle.demo.adfglitz.watermark - I'll use this to associate an implementation class with the tag
  • The attributes.  Note that I've defined one attribute for the tag called value. I'll use this to pass the actual text that needs to be displayed in the placeholder.

You can switch to the source view of the editor and provide more information such as a friendly description of the taglib and tag, but you don't actually need to. 

Implement the Behavior

 Next we need to actually create a class that provides the implementation of the behavior. This needs to extend javax.faces.component.behavior.ClientBehaviorBase and implement javax.faces.component.StateHolder. The latter interface implementation is to ensure that the String passed in as the value of the tag is persisted and will survive re-builds of the component tree. 

The basic class definition therefore looks like this: 

public class SetWatermarkBehavior extends ClientBehaviorBase implements StateHolder {...}

Note that I use the FacesBehavior annotation  to do the wiring between this implementation class and the taglib using the ID attribute defined above.

The other thing we need to implement the tag contract is the "value" that must be passed in as a  required attribute for the tag.  This is done with a simple member variable (String value;) and an associated public getter and setter pair on the class - getValue(), setValue() - standard stuff. We also have to manage the storage of this value by implementing the StateHolder interface. The code for that is not very interesting so I'll not reproduce it here, you can see it in the complete java class though.

The core method within the behavoir class is the getScript() method. This is called to encode the JavaScript  to send down with the enclosing component, however, we're going to subvert it a little - let me explain why.  If you have a clientBehavior associated with an inputItem then any script that you return from the getScript() method will be associated with a value change listener on the component.  In this case, that's not what we want, rather than applying the watermark when the value of the input changes, we want to apply it at the point in time the component is rendered. So to achieve this we actually just use and abuse the getScript() call and use the Trinidad ExtendedRenderKitService to queue up execute the JavaScript we need in a just in timely way.

Here's the implementation of the method:

//Constants used by getScript() defined at class level
private static final String SCRIPT_PREFIX = "addWatermarkBehavior(\"";
private static final String SCRIPT_ARG_SEPARATOR = "\",\""; 
private static final String SCRIPT_SUFFIX = "\");"; 
public String getScript(ClientBehaviorContext ctx) {
  UIComponent component = ctx.getComponent();
  //only contiune if the component is currently rendered
  if (component.isRendered()) {
    String componentType = deduceDOMElementType(component);
    //Only continue if the component is a valid type
    if (!componentType.equals(UNSUPPORTED_ELEMENT)) {
      String wmText = (getValue() == null) ? EMPTY_DEFAULT : getValue();
      StringBuilder script = new StringBuilder(SCRIPT_PREFIX);

      //We don't have an init event, just valueChange so push the code this way
      FacesContext fctx = ctx.getFacesContext();
      ExtendedRenderKitService extendedRenderKitService =
               Service.getRenderKitService(fctx, ExtendedRenderKitService.class);
      extendedRenderKitService.addScript(fctx, script.toString());
  //And return nothing as we don't need a valuechangeListener
  return "";

Things to note here.  We could of course encode the entire JavaScript  function within the script string generated above. However, given that in my case, I have several uses of the behavior in the app it makes sense to shove the detail of that code into a common .js file. I already have this available on the page and call a simple function - addWatermarkBehavior(), passing the relevant component ID, type and placeholder value.  That JavaScript can be seen below.

Another point is that getScript() uses the convenience method deduceDOMElementType() which, from the component and its attributes works out: First of all if it's a valid component on which to do anything, and secondly if the placeholder will need to be set on an html <input> element or an <textarea>.

//Constants used by deduceDOMElementType() defined at class level
private static final String UNSUPPORTED_ELEMENT = "unsupported";
private static final String TEXTAREA_ELEMENT = "textarea";
private static final String INPUT_ELEMENT = "input";

private String deduceDOMElementType(UIComponent component) {
  String componentType = UNSUPPORTED_ELEMENT;
  //work out the correct component type
  if (component instanceof RichInputText) {
    //In this case we may have a multi-line item but assume intially that this is not the case
    componentType = INPUT_ELEMENT;
    //Now check for the rows attribute to see if this is multi-line
    Map<String, Object> compAttr = component.getAttributes();
    if (compAttr.containsKey("rows")) {
      int rows = (Integer)compAttr.get("rows");
      if (rows > 1) {
         componentType = TEXTAREA_ELEMENT;
  } else if (component instanceof RichInputDate || 
             component instanceof RichInputListOfValues ||
             component instanceof RichInputComboboxListOfValues) {
    //These all resolve to inputs at the DOM level
    componentType = INPUT_ELEMENT;
  return componentType;

The JavaScript

 As I mentioned above, rather than stream down reams of script for each component I have a standard JavaScript file attached to my page using the <af:resource> tag and in that I've implemented the simple function to locate the correct component on the page and apply the correct placeholder text. You could also use this method as a place to add a script based solution to browsers that don't support placeholder. Here's the  function:

function addWatermarkBehavior(componentId, type, text){
    var sourceInput = AdfPage.PAGE.findComponent(componentId);
    var domElemement = AdfAgent.AGENT.getElementById(sourceInput.getClientId());
    var targetArray = domElemement.getElementsByTagName(type);
    targetArray[0].placeholder = text;

As you can see, pretty short and sweet, you could of course add various validations to check you have a real element  etc. but let's keep it simple.

Using the Behavior

So that's about it. The final point is, of course how to use this. Well all you need to do is register the namespace in your page or fragment as I've done here using the afg: prefix:

<ui:composition xmlns:ui="" 

And then use the tag thus:

<af:inputText ...>
  <afg:setWatermarkBehaviour value="Filter Items"/> 


Tuesday Apr 24, 2012

Using inputNumberSlider for Dates

I'm currently working on a prototype User Interface for an internal project that surfaced a requirement for allowing date selection using a slider control.  ADF Faces itself only supports two forms of slider control (<af:inputNumberSlider> and <af:inputRangeSlider>) , so what to do? Well putting aside for one moment the aesthetic and usability of using a slider for date selection ( not something I wholly buy into myself), can it be done? 

The simple answer is (of course and hence the article) yes.

Is it a Date? Is it a Number? 

Fortunately it's both. Java dates are stored internally as longs so there is no fundamental issue with using the inputNumberSlider to select one, providing that we get the precision right - milliseconds are probably not that useful as an increment. However, if we try and base a inputNumberSlider on the millisecond value of a date, the main problem is going to be the labels - in fact here's what it might look like:

Time slider with default labelling

So how do we  use this component but convert the labels to something sensible such as dates in the format "MM/dd", ending up with this:

Tome slider with corrected labelling

Well to achieve that we need a custom converter which can be assigned to the converter property of the component thus:

<af:inputNumberSlider label="Pick a day" id="ins1"

Defining The Converter

 Before I proceed here, credit has to go to my good buddy Matthias Wessendorf who's code from this article I have freely adapted here.

To define the converter, there are three steps:

  1. Write a server side converter in Java. 
  2. Write a client-side converter in JavaScript
  3. Register the converter with Faces 

The Server Side Converter Class

The server side converter is called by the framework as it initially renders the component on the page. It will call into this class several times to generate the major tick labels and of course the label for the slider value.  The converter class needs to implement two interfaces; org.apache.myfaces.trinidad.convert.ClientConverter and javax.faces.convert.Converter. In this case I've only had to implement four methods, two of which relate to the wiring up of the client JavaScript to the converter and the others manage the conversion itself. Let's look at those latter two first. 

Converters in JSF handle the basic problem of taking a value Object  and converting it into a String form that can be sent down to the browser in HTML and then the reverse of that cam task of taking the String value that gets sent up on the request and converting that back into the Object value form. 

So in this case we're attempting to convert a Long object (for convenience I'm actually storing the value as a long and then providing a typed getter to provide the actual date value when it's asked for). The conversion will be something like this:

1335135600000 --> "04/24"

So this paired conversion is handled by two methods called getAsString() and getAsObject() and the implementations are pretty simple - just a bit of string parsing and date arithmetic / formatting. I'm using the org.apache.commons.lang.time.DateFormatUtils helper class as well:

public String getAsString(FacesContext facesContext, UIComponent uIComponent, Object valueAsObject) {
  long selectedValue =  ((Double)valueAsObject).longValue();
  return DateFormatUtils.format(selectedValue, "MM/dd");
public Object getAsObject(FacesContext facesContext, UIComponent uIComponent, String valueAsString) {
  Calendar cal = new GregorianCalendar();
  int currentMonth = cal.get(Calendar.MONTH); /* Zero based */
  int currentYear = cal.get(Calendar.YEAR);
  //Parse the supplied String assuming the format MM/dd in this case
  String[] dateBits = valueAsString.split("[/]");
  int month = Integer.parseInt(dateBits[0]) - 1;
  int day = Integer.parseInt(dateBits[1]);
  int year = currentYear;
  //Handle the situation where the span crosses a year boundary
  //In my specific use case the dates all work backwards from today
  if (month > currentMonth){
  //Reconstruct the actual date
  Calendar selectedAsDateCal = new GregorianCalendar(year,month,day);
  return selectedAsDateCal.getTimeInMillis();

So the only complexity in this case is in the case where the selected String value is something like "11/30" which, because the range of my slider extends into the past from the current date, has to be interpreted as 30th November 2011 not 30th November 2012. Of course if you are trying to create a slider that extends across multiple years you'll have to encode the year into the string as well - month and day alone will not give you enough information.

The second two methods I need to implement wire up the JavaScript. The function getClientLibrarySource() tells the framework what .js file the client converter is in and  getClientConversion() defines the name of the converter function:

public String getClientLibrarySource(FacesContext facesContext) {
  return facesContext.getExternalContext().getRequestContextPath() + 

public String getClientConversion(FacesContext facesContext, UIComponent uIComponent) {
  return ("new SliderDateReformatter()");

The Client Side Converter 

 As specified above, the client converter is defined in a file called sliderDateConverter.js in my PUBLIC_HTML/resources/js directory. This converter is called as the use moves the slider around, so unlike the server side code which is used to format the labels as well, this is really just used to format the label on the selector and it's value tooltip.  The underlying logic is essentially identical to the Java version just converted to JavaScript. Again it's just a matter of methods to convert from Object to String and back. You'll note here as well, that the prototype of the SliderDateReformatter  is set to TrConverter, this is the equivalent, to implementing the Converter interface in Java terms.

function SliderDateReformatter()

SliderDateReformatter.prototype = new TrConverter();

SliderDateReformatter.prototype.getFormatHint = function()
	return null;

SliderDateReformatter.prototype.getAsString = function(dateMillis,label) {
	var asDate  = new Date(dateMillis);
        var month = asDate.getMonth()+1; /* Again zero based */
        var day = asDate.getDate();
	return month + "/" + day;

SliderDateReformatter.prototype.getAsObject = function(dateString,label){
        var dateNow = new Date();
        var currentYear = dateNow.getFullYear();
        var currentMonth = dateNow.getMonth();
        var dateBits = dateString.split("/");
        var selectedMonth = (dateBits[0]) - 1;
        var selectedDay = dateBits[1];
        var selectedYear = currentYear;
        if (selectedMonth > currentMonth){
        var representedDate = new Date(selectedYear,selectedMonth,selectedDay);
	return representedDate.getTime();

Register the Converter

 The final step is to register the converter by name in the faces-config.xml file. This allows the framework to match the reference converter="SliderDateConverter" made by the component with the actual converter class. Just edit the faces-config and set this in the Overview editor Converters page, or add it directly to the XML, thus:

<faces-config version="2.1" xmlns="">

Wrap Up

So as we've seen it's not too difficult to use the inputNumberSlider to represent data that, at first glance, is not numerical.  The same technique can be used to control the tick labelling of the component, even when you are dealing with "real" numbers, for example you might want to define a slider that allows the user to pick a percentage from the range 1%-100% and map that onto an underlying value of 0.01 to 1. You'd use exactly the same technique to do so if you were writing things from scratch, however, that one's already handled for you! Just embed a <af:convertNumber type="percent"/> as a child of the component.

We can also use the same technique for <af:inputRangeSlider> as well.

Friday Apr 13, 2012

Skinning af:selectOneChoice

A question came in today about how to skin the selection button (Image of a drop down list)  of an <af:selectOneChoice>. If you have a delve in the ADF Skinning editor, you'll find that there are selectors for the selectOneChoice when in compact mode (af|selectOneChoice::compact-dropdown-icon-style), however, there is not a selector for the icon in the "normal" mode. I had a quick delve into the skinning source files that you can find in the adf-richclient-impl-11.jar and likewise there seemed to be no association there. However, a quick sample page and a peek with Chrome developer tools revealed the problem.  The af:selectOneChoice gets rendered in the browser as a good old <select> element (reasonable enough!). Herein lies the problem, and the reason why there is no skin selector. The <select> HTML element does not have a standard way of replacing the image used for the dropdown button.  If you have a search around with your favorite search engine, you can find various workarounds and solutions for this.  For example, using Chrome and Safari you can define the following for the select element:

select {
  -webkit-appearance: listbox;
  background-image: url(blob.png); 
  background-position: center right;
  background-repeat: no-repeat;

Which gives a very exciting select box: Image of updated selectOneChoice .

Wednesday Apr 11, 2012

More Animation - Self Dismissing Dialogs

In my earlier articles on animation, I discussed various slide, grow and  flip transitions for items and containers.  In this article I want to discuss a fade animation and specifically the use of fades and auto-dismissal for informational dialogs.  If you use a Mac, you may be familiar with Growl as a notification system, and the nice way that messages that are informational just fade out after a few seconds. So in this blog entry I wanted to discuss how we could make an ADF popup behave in the same way. This can be an effective way of communicating information to the user without "getting in the way" with modal alerts. This of course, has been done before, but everything I've seen previously requires something like JQuery to be in the mix when we don't really need it to be. 

The solution I've put together is nice and generic and will work with either <af:panelWindow> or <af:dialog> as a the child of the popup. In terms of usage it's pretty simple to use we  just need to ensure that the popup itself has clientComponent is set to true and includes the animation JavaScript (animateFadingPopup) on a popupOpened event:

<af:popup id="pop1" clientComponent="true">
  <af:panelWindow title="A Fading Message...">
  <af:clientListener method="animateFadingPopup" type="popupOpened"/>

 The popup can be invoked in the normal way using showPopupBehavior or JavaScript, no special code is required there.

As a further twist you can include an additional clientAttribute called preFadeDelay to define a delay before the fade itself starts (the default is 5 seconds) . To set the delay to just 2 seconds for example:

<af:popup ...>
  <af:clientAttribute name="preFadeDelay" value="2"/>
  <af:clientListener method="animateFadingPopup" type="popupOpened"/> 

The Animation Styles 

As before, we have a couple of CSS Styles which define the animation, I've put these into the skin in my case, and, as in the other articles, I've only defined the transitions for WebKit browsers (Chrome, Safari) at the moment. In this case, the fade is timed at 5 seconds in duration.

.popupFadeReset {
  opacity: 1;

.popupFadeAnimate {
  opacity: 0;
  -webkit-transition: opacity 5s ease-in-out;

As you can see here, we are achieving the fade by simply setting the CSS opacity property.

The JavaScript

The final part of the puzzle is, of course, the JavaScript, there are four functions, these are generic (apart from the Style names which, if you've changed above, you'll need to reflect here):

  1. The initial function invoked from the popupOpened event,  animateFadingPopup which starts a timer and provides the initial delay before we start to fade the popup.
  2. The function that applies the fade animation to the popup - initiatePopupFade.
  3. The callback function - closeFadedPopup used to reset the style class and correctly hide the popup so that it can be invoked again and again.  
  4. A utility function - findFadeContainer, which is responsible for locating the correct child component of the popup to actually apply the style to.

Function - animateFadingPopup

This function, as stated is the one hooked up to the popupOpened event via a clientListener. Because of when the code is called it does not actually matter how you launch the popup, or if the popup is re-used from multiple places. All usages will get the fade behavior.

 * Client listener which will kick off the animation to fade the dialog and register
 * a callback to correctly reset the popup once the animation is complete
 * @param event
function animateFadingPopup(event) {
  var fadePopup = event.getSource();
  var fadeCandidate = false;
  //Ensure that the popup is initially Opaque
  //This handles the situation where the user has dismissed
  //the popup whilst it was in the process of fading
  var fadeContainer = findFadeContainer(fadePopup);
  if (fadeContainer != null) {
    fadeCandidate = true;
  //Only continue if we can actually fade this popup
  if (fadeCandidate) {
    //See if a delay has been specified
    var waitTimeSeconds = event.getSource().getProperty('preFadeDelay');
    //Default to 5 seconds if not supplied
    if (waitTimeSeconds == undefined) {
      waitTimeSeconds = 5;
    // Now call the fade after the specified time
    var fadeFunction = function () {
    var fadeDelayTimer = setTimeout(fadeFunction, (waitTimeSeconds * 1000));

The things to note about this function is the initial check that we have to do to ensure that the container is currently visible and reset it's style to ensure that it is.  This is to handle the situation where the popup has begun the fade, and yet the user has still explicitly dismissed the popup before it's complete and in doing so has prevented the callback function (described later) from executing. In this particular situation the initial display of the dialog will be (apparently) missing it's normal animation but at least it becomes visible to the user (and most users will probably not notice this difference in any case).

You'll notice that the style that we apply to reset the  opacity - popupFadeReset, is not applied to the popup component itself but rather the dialog or panelWindow within it. More about that in the description of the next function findFadeContainer().

Finally, assuming that we have a suitable candidate for fading, a JavaScript  timer is started using the specified preFadeDelay wait time (or 5 seconds if that was not supplied). When this timer expires then the main animation styleclass will be applied using the initiatePopupFade() function

Function - findFadeContainer

As a component, the <af:popup> does not support styleClass attribute, so we can't apply the animation style directly.  Instead we have to look for the container within the popup which defines the window object that can have a style attached.  This is achieved by the following code:

 * The thing we actually fade will be the only child
 * of the popup assuming that this is a dialog or window
 * @param popup
 * @return the component, or null if this is not valid for fading
function findFadeContainer(popup) {
  var children = popup.getDescendantComponents();
  var fadeContainer = children[0];
  if (fadeContainer != undefined) {
    var compType = fadeContainer.getComponentType();
    if (compType == "oracle.adf.RichPanelWindow" 
     || compType == "oracle.adf.RichDialog") {
      return fadeContainer;
  return null;

 So what we do here is to grab the first child component of the popup and check its type. Here I decided to limit the fade behaviour to only <af:dialog> and <af:panelWindow>. This was deliberate.  If  we apply the fade to say an <af:noteWindow> you would see the text inside the balloon fade, but the balloon itself would hang around until the fade animation was over and then hide.  It would of course be possible to make the code smarter to walk up the DOM tree to find the correct <div> to apply the style to in order to hide the whole balloon, however, that means that this JavaScript would then need to have knowledge of the generated DOM structure, something which may change from release to release, and certainly something to avoid. So, all in all, I think that this is an OK restriction and frankly it's windows and dialogs that I wanted to fade anyway, not balloons and menus. You could of course extend this technique and handle the other types should you really want to.

One thing to note here is the selection of the first (children[0]) child of the popup. It does not matter if there are non-visible children such as clientListener before the <af:dialog> or <af:panelWindow> within the popup, they are not included in this array, so picking the first element in this way seems to be fine, no matter what the underlying ordering is within the JSF source.  If you wanted a super-robust version of the code you might want to iterate through the children array of the popup to check for the right type, again it's up to you. 

Function -  initiatePopupFade

 On to the actual fading. This is actually very simple and at it's heart, just the application of the popupFadeAnimate style to the correct component and then registering a callback to execute once the fade is done.

 * Function which will kick off the animation to fade the dialog and register
 * a callback to correctly reset the popup once the animation is complete
 * @param popup the popup we are animating
function initiatePopupFade(popup) {
  //Only continue if the popup has not already been dismissed 
  if (popup.isPopupVisible()) {
    //The skin styles that define the animation 
    var fadeoutAnimationStyle = "popupFadeAnimate";
    var fadeAnimationResetStyle = "popupFadeReset";

    var fadeContainer = findFadeContainer(popup);
    if (fadeContainer != null) {
      var fadeContainerReal = AdfAgent.AGENT.getElementById(fadeContainer.getClientId());
      //Define the callback this will correctly reset the popup once it's disappeared
      var fadeCallbackFunction = function (event) {
        closeFadedPopup(popup, fadeContainer, fadeAnimationResetStyle);"webkitTransitionEnd", fadeCallbackFunction);
      //Initiate the fade
      //Register the callback to execute once fade is done
      fadeContainerReal.addEventListener("webkitTransitionEnd", fadeCallbackFunction, false);

I've added some extra checks here though. First of all we only start the whole process if the popup is still visible. It may be that the user has closed the popup before the delay timer has finished so there is no need to start animating in that case. Again we use the findFadeContainer() function to locate the correct component to apply the style to, and additionally we grab the DOM id that represents that container.  This physical ID is required for the registration of the callback function. The closeFadedPopup() call is then registered on the callback so as to correctly close the now transparent (but still there) popup.

Function -  closeFadedPopup

The final function just cleans things up:

 * Callback function to correctly cancel and reset the style in the popup
 * @param popup id of the popup so we can close it properly
 * @param contatiner the window / dialog within the popup to actually style
 * @param resetStyle the syle that sets the opacity back to solid
function closeFadedPopup(popup, container, resetStyle) {

First of all we reset the style to make the popup contents opaque again and then we cancel the popup.  This will ensure that any of your user code that is waiting for a popup cancelled event will actually get the event, additionally if you have done this as a modal window / dialog it will ensure that the glasspane is dismissed and you can interact with the UI again. 

What's Next?

There are several ways in which this technique could be used, I've been working on a popup here, but you could apply the same approach to in-line messages. As this code (in the popup case) is generic it will make s pretty nice declarative component and maybe, if I get time, I'll look at constructing a formal Growl component using a combination of this technique, and active data push. Also, I'm sure the above code can be improved a little too.  Specifically things like registering a popup cancelled listener to handle the style reset so that we don't loose the subtle animation that takes place when the popup is opened in that situation where the user has closed the in-fade dialog.

Wednesday Feb 29, 2012

CSS Animations - The Panel Flip

In the my final (for now) discussion on CSS3 animations with ADF Faces Rich Client  UI I wanted to discuss the most complex, but fundamentally useful (from a technique perspective) of the three animations shown in the introduction posting. The first two animations that I showcased were simply triggered by the browser's inherent mouse-over functionality. I didn't actually need to do anything to make the animation happen apart from assigning the correct styleClass to the panel or button.  In this final animation I'm triggering the animation from code and what's more I'm actually chaining together two animations with a server side call made in the middle. To break it down here's the logical flow:

Initiate a rotation of 90 degrees --> Change the contents of the panel -->  Return rotation to 0 degrees.

So the question is, how do we chain all of these actions together, given that the initial rotation will itself take a certain amount of time (2 seconds)?  Well, to handle this we have to write a little bit of JavaScript  that will first of all set the styleClass to provide the first 90deg animation and also register a listener function which will execute once the rotation is finished.  This callback function then executes the Server code we need and then kicks off the reverse animation. 

The Animations  

So first of all, the two styles that define the animations. This should be fairly obvious and understandable by now:

.rotateOut {
    -webkit-transition-property: -webkit-transform;
    -webkit-transform: rotateY(90deg);
    -webkit-transition-timing-function: ease-in-out;
    -webkit-transition-duration: 2s;
.rotateReturn {
    -webkit-transition-property: -webkit-transform;
    -webkit-transform: rotateY(0deg);
    -webkit-transition-timing-function: ease-in-out;
    -webkit-transition-duration: 2s;

The JSF components

In this example I'm using a switcher which is controlled by a managed bean  called uiManager. This switcher will either display the panelHeader that contains the inputForm or the comments screen. Contrary to your expectation though, it's not these panels managed by the switcher that we'll actually be animating, but rather a parent of the switcher, another panelGroupLayout. So the hierarchy looks a  like this:

  1. Panel group layout that will be animated
  2. Decorative box that will apparently rotate  
  3. Panel group layout that will be refreshed to show the change in contents
  4. Switcher 
<af:panelGroupLayout layout="vertical" 
<af:decorativeBox theme="dark">
  <f:facet name="center">
      <af:panelGroupLayout id="refresh" 
        <af:switcher defaultFacet="ASide" 
                     facetName="#{uiManager.flipAnimationSelectedSide}" >
          <f:facet name="ASide">
            <af:panelHeader text="Basic Information"> 
          <f:facet name="BSide"> 
            <af:panelHeader text="Comments">

Notice that the outer panelGroupLayout id="flip" has a binding to a backing bean for the page, this is so we can get the correct clientId back for it (look back at my Visual Notifications During Long Running Transactions article for details of this technique). The inner pgl, id="refresh", also has a binding to the backing bean which we will use later in the serverListener to force a refresh on that panel and the switcher inside it.

 Within each of the switcher "panels" is a button (not shown above) that will actually trigger the animation.  Here's the code for the button on the A-Side:

<af:commandButton text="More..." 
  <af:clientAttribute name="flipPanel"
  <af:clientListener method="animateFlipPanel"
  <af:serverListener type="flipEvent"

The code for the B-Side button is identical. To break that down we have three things of interest:

  1. A clientAttribute that is used to send the client id of the panel that we want to spin to JavaScript
  2. A clientListener to actually wire up a JavaScript  event to the button press
  3. A serverListener which identifies the server side method that will be called half way through the animation to tell the switcher to change contents.

So let's look at each of those:

The Client Attribute

The client attribute is bound to the page backing bean where there is a simple function that asks the panel that will be "flipped" for it's client ID, in this case the flipPanel variable contains the reference to the RichPanelGroupLayout which is bound to that outer panel:

 * Gets the correct client component ID for this panel in the context in which the 
 * panel is placed. This provides a safe way of getting the client ID if the component
 * is embedded in a region or similar where the computed path may change depending on the use.
 * @return clientID for use in JavaScript 
 public String  getFlipClientId() {
   return flipPanel.getClientId(FacesContext.getCurrentInstance());

The JavaScript

The clientListener on the button calls the animateFlipPanel method. This is stored in a .js file referenced using the <af:resource> tag in the metaContainer facet of the document:

function animateFlipPanel(event) {
    //Get the ID of the panel to flip. 
    //This has been passed in via the clientAttribute 
    var fpId = event.getSource().getProperty('flipPanel');
    //Grab a reference to this button that raised the 
    //event. we need this to register the callback against
    var raisingComponent = event.getSource();

    //First animation sends us to 90deg
    var transition = "rotateOut";
    flipPanel = AdfPage.PAGE.findComponentByAbsoluteId(fpId);
    initiateClientFlip(raisingComponent, flipPanel, transition);

 And here's the method that assigns the animation:

 * Kick off the animation - rotate the panel to 90 degrees which will make it  
 * disappear as it's sideways on to us.
 * Then register the callback to rotate back once the animation is finished
 * @param raisingComponent - the button that kicked things off
 * @param flipPanel - the PGL to animate (assign style to) 
 * @param transition - the style to apply
function initiateClientFlip(raisingComponent, flipPanel, transition) {
  //Set the style to animate the rotation
  /* Setup a callback to reverse the animation once the transition is finished.
   * Note that we remove the transition listener once it's executed so that 
   *   it is not called by the flipBack transition as well 
   * Note also that we have to attach the listener to the underlying DOM object
  // Get the DOM object that represents this panelGroupLayout
  var flipPanelReal = AdfAgent.AGENT.getElementById(flipPanel.getClientId());
  //Define the callback 
  var reverseTransition = "rotateReturn"
  var flipBackFunction = function (event) 
           {animateFlipBack(raisingComponent, flipPanel, reverseTransition); 
  // Add the transition listener to queue up both the animation back  
  // and the server side change which will apparently flip the
  // contents of the panel 
  flipPanelReal.addEventListener("webkitTransitionEnd", flipBackFunction,false);

So the actual animation part of the above code is trivial, we just set the new style to kick that off.  The exciting part comes in the definition of the eventListener (webkitTransitionEnd) which is set up to execute once the animation has finished. Like everything that I have covered in this short series, the code here is webkit (Chrome & Safari) specific. Similar events exist both in generic terms for the future and in specific versions for FireFox and IE.

And finally the animateFlipBack() function and a convenience method that it uses:

 * Once the initial animation is done this method is invoked to change the contents of the panel and then
 * animate back to the starting point giving the illusion of a full 180 degree flip
 * @param raisingComponent - reference to the button so we can invoke the serverListener
 * @param flipPanel - pgl to animate
 * @param reverseTransition - animation style
function animateFlipBack(raisingComponent, flipPanel, reverseTransition) {
  // Call the event on the server which will cause the switcher to 
  // change it's contents and issue a PPR event

  //Now start the return animation

 * Simple function to queue up the server side event on the button that 
 * instigated the flip. This event does not need to send a payload
 * @param raisingComponent - the button 
function raiseServerFlipEvent(raisingComponent){
    var flipEvent = new AdfCustomEvent(raisingComponent,"flipEvent",{},false);

The serverListener 

The role of the serverListener code is to toggle the facet that the switcher is currently displaying and then force the panel containing the switcher to refresh with a PPR event:

 * Event raised from JavaScript to tell us that the flip animation is underway and we 
 * need to change the content on the panel 
 * @param clientEvent
public void handlePanelFipEvent(ClientEvent clientEvent) {
  String currentSide = _uiManager.getFlipAnimationSelectedSide();
  String targetSide = UIManager.A_SIDE;
  if (currentSide.equals(UIManager.A_SIDE)){
      targetSide = UIManager.B_SIDE;
  }"Flipping to " + targetSide);
  // And queue the client refresh

 This function as you can see is a toggle based on the current value stored in the uiManager.  The UIManager itself is a session scoped bean that just holds the current side value.  It is injected into this backing bean using a managed property in the managed bean definition. The function getRefreshPanel() returns a reference to the pgl that surrounds the switcher (id="refresh" in the hierarchy above). 

Wrap Up 

The technique that I've discussed within this article may seem a little complex but in fact it's all quite logical and can be quite easily extended and made generic. You can see how more complex animations may be achieved by stringing together a whole sequence of callbacks to execute after the previous animation has completed and how you can wire in server side calls into the mix. 

Tuesday Feb 21, 2012

CSS Animations - Slide Out Panel

In this second the detailed articles on the animation prototype I'm going to look at the animation of a whole group of components at once in the form of a slide out panel menu effect. This animation combines two effects (if you look closely),  The actual slide-out, and, in parallel, a shadow around the panel.  Just like the first example, no Java or JavaScript code is required for this example, we can just use default CSS hover functionality to trigger the animation.

Again, just a warning.  This prototype was only set up for the WebKit based browsers (Safari and Chrome). So where I talk about -webkit* styles below be aware that these will have different names on FireFox (usually -moz*) and IE. A stylesheet that handles more browsers will have to include these versions as well. 

The start point for this article assumes that your style sheet (via a custom skin) already exists (go back to the first article if you've not read this yet).

However, before we get too excited about the animations we need to think a little about layout.  The last thing we want to do with these funky effects is to mess up the rest of the screen, and so at this stage, where we've not got any scripting involved, we need to make sure that space is available in the UI for the slide out. To do this I started out by laying out my components thus:

<af:panelGroupLayout (Horizontal)>
  <af:panelGroupLayout (Vertical)> - will be animated
  <af:spacer .../>  
  <af:panelGroupLayout (Vertical)>
    [Decorative Box etc.] 

So basically the panelGroupLayout that will be animated already has space "reserved" for it on the screen and, at design time, it occupies that slot. At this stage you also need to work out how wide the panel that you are animating will be once populated. This is so you can push it off screen, but still expose enough for the mouse to hover over. In my case the pgl comes out at around 100px once populated.

Hint: To keep things simple with these "container" animations I recommend that you attach effects to a vertical panelGroupLayout. In HTML terms these components get rendered as a simple html <div> which is perfect and makes things much easier to debug if the styles don't seem to be working.

On to the animation. When I started this animation I was not sure what components I would be animating so, rather than defining a specific sub-type as I did for the button in the last article, I'm defining a generic styleClass that could be used with any components. Again we need the base class(.slideout) and the :hover selector for it.


Again concentrating on the base selector first, let's look at the transitions. This time I'm kicking it up a notch (to coin a phrase) by desiring two concurrent animations, the slide out and the shadow.  Just like the last example with the commandButton we want to pair effects so that any effect I put on the hover needs to be mirrored and reversed by the base selector. This way, both the mouse-over and mouse-out will be smoothly animated.

So here's the base selector.  This "parks" the panel off screen with a little bit hanging out for the mouse to hover over and start the animation:

  position: relative;
  -webkit-transition-property: left, -webkit-box-shadow; ;  
  -webkit-transition-timing-function: linear, ease-out;
  -webkit-transition-duration: 1s, 1s;  
  -webkit-box-shadow: 0px 0px 0px;
  left: -80px; 

The story here is going to be similar to the simple button scaling discussed in part 1, but there are some differences worthy of mention.  First of all the position property. As part of this animation we're actually moving a <div> and all it's contents around the screen. I want to do that in relation to it's initial position (remember that we started out with the panel in a conventional layout). So the relative keyword is used for this. The other option here is absolute. Try setting this to absolute if you give this a go, you'll notice that the results can be, shall we say unpredictable. You need to be really careful if you're trying to move things around out of context and could end up fighting with the ADF layout algorythms. So stick to relative for now!

Next the -webkit-transition-property - this time it contains two properties, separated by a comma: left and -webkit-box-shadow. So I'm declaring here that those are the two properties I'll be animating the change in. As I'm now dealing with two properties the other -webkit-transition* properties also contain two values separated by a comma and those refer to each property transition. Thus if you look at the timing function, you'll see how the animation in the change of the left value will be linear whereas the shadow will use the ease-in-out rate of change just like the button did.  Again have a play with this and see what the difference is between the timing effects, you have total control. 

Both animations take place concurrently and take place over the same 1s duration although they could be of different durations.  In the next article I'll be looking at how animations can be queued up to provide more complex effects. 

Finally we have the endpoints for  the shadow (basically no shadow) and left. Notice with the left property, it is set to -80px. Recall that the positioning for this style is relative, so this really just tells the panel to shift 80px to the left from its starting position, which happens, in this case, to place it mostly, but not quite all, off screen.

Next the hover selector, it is, as you would expect pretty similar except that we move the pgl back to where it belongs at 0px (relative) and introduces some shadow:

  position: relative;
  -webkit-transition-property: left, -webkit-box-shadow;  
  -webkit-transition-timing-function: linear, ease-in;
  -webkit-transition-duration: 1s, 1s;  
  -webkit-box-shadow: 10px 10px 5px #888;
  left: 0px;

The final step is, of course, to assign this style to the pgl itself. Again this is done with the styleClass property 

<af:panelGroupLayout id="pglmenu" layout="vertical" styleClass="slideout"> 

There you have it.  In the final article in this series I'll be investigating a more complex animation involving JavaScript and other goodies - stay tuned! 

Monday Feb 20, 2012

CSS Animations - Basic Hover Scaling

In this first of the detailed articles on the animation prototype I wanted to look at the basic setup of application and the simplest of the animations - the Pick Me! button.  The Pick Me! button animates to draw attention to itself as the mouse moves over it.  The actual animation itself is a simple scaling so it's a good place to start. 

Again, just a warning.  This prototype was only set up for the WebKit based browsers (Safari and Chrome). So where I talk about -webkit* styles below be aware that these will have different names on FireFox (usually -moz*) and IE. A stylesheet that handles more browsers will have to include these versions as well. 

The basis of all of this work is a custom skin so that's the first thing to create. In 11.1.2 this is really as simple as going to the New Gallery and creating a new skin in the project.  Here I've extended the fusionFx-simple-v2.desktop skin as I want to keep the standard look and feel.  If you've not created a skin for your applications before, there are plenty of articles out there to help you, so I won't dwell on that.

Now in the skin itself I want to create a sub-type of button which will do the animation.  I don't want to animate every button, that would probably make the users seasick.  So the first step is to create a sub-type of the button thus:


This sub-type can then  applied to the selected buttons using the styleClass property:

<af:commandButton text="Pick Me!" styleClass="zoomOnFocus" ...>

Now to implement the  zoom behaviour, fortunately this does not involve writing any code apart from the actual CSS to provide the style. To do this we define a :hover selector for the zoomOnFocus in the skin:


Now we fill that in with the desired animation, I'll explain each of the lines next:

  -webkit-transition-property: -webkit-transform;
  -webkit-transform: scale(2,2); 
  -webkit-transition-timing-function: ease-in-out;
  -webkit-transition-duration: 1s;  

The first line,  -webkit-transition-property defines which property, -webkit-transform, should be animated. The second line -webkit-transform itself defines the end result of the animation which is a scale function. This takes two arguments for the x and y scaling respectively, so scale(2,2) doubles the size of the button in both directions.

The third line  -webkit-transition-timing-function, defines the progression of the animation in time. There are various options for this, the ease-in-out function starts the animation slowly, then speeds up and then slows down again towards the end. This provides a pleasing effect to the eye.

Finally -webkit-transition-duration defines how long the animation should take.

If you do all of this, the zoom will work nicely as you move the mouse over the button, however, as you move the mouse out the style will snap back instantly, so we need to complete the recipe with an animation the other way on the base style:

  -webkit-transition-property: -webkit-transform;
  -webkit-transform: scale(1,1); 
  -webkit-transition-timing-function: ease-in-out;
   -webkit-transition-duration: 1s;  

This style is pretty much identical to the :hover version.  The only difference is the scale() factor which is changed to 1,1 to return the button to it's normal size.  With this all in place, the button will gracefully shrink back to its normal size. 

So that's the first, very simple animation, in the next article in the series I'll look at the only slightly more complex slide-out panel animation. 

Friday Feb 17, 2012

Experiments with CSS animations in ADF Applications - Introduction

We have had several ADF users experimenting with JQuery to achieve animation effects and that made me wonder how feasible it would be to work with pure CSS3 animations within the context of an ADF application.  From the point of view of the product, we're thinking about how we might express a broader range of animations in a declaritive way, but for now I wanted to see what was possible with the product as it stands.  To wet your appetite, here's a short video of my initial prototype.  I'll explain all of the effects in follow up articles - so be patient with me and, of course, keep coming back to the blog for more!

This prototype was written in, but there is nothing there that would not work in 11.1.1.n. Also I've only worked with WebKit browsers (Chrome / Safari so far),  this is still an area where the different browser families need different treatment. This will be an exercise for you the reader. 

If you have an up to date version of Chrome, Safari or IE9 you can play the following short video in-line, Firefox users, sorry I had problems with encoding to ogg format, you'll have to download:

If not download it from here (Size: 374k) 

I've used three sets of animations here:

  1. Simple animated zoom on the Pick Me! button. It grows and then shrinks as the mouse moves over and out.
  2. Panel slide-out effect with shadow for the "menu" panel.
  3. Panel flip effect where the panel rotates through 180 degrees to show some different content, the kind of effect you'll see on your phone fairly often. (I'll admit that this one is very cool)

Tuesday Jan 24, 2012

Visual Notification During Long Running Transactions

From time to time, there will be transactions within your application which do not finish within the "blink of an eye". Later this week I'll be writing up a series of articles specifically on launching long running tasks asynchronously, but first I wanted to cover the case of a transaction which has to happen in real-time but ties up the browser whilst it's doing so. 

A file upload is a typical example of this. The user selects a 500MiB file and presses submit, it's probably time to go and get a cup of tea.  So the question is, how do you tell the user to go and find something more interesting to do for a while and, for that matter, please don't close your browser window...

Both Frank Nimphius and Andrejus Baranovskis have written articles in the past  (How-to show a glasspane and splash screen for long running queries and ,Glasspane in ADF Faces RC, respectively). However, both of those articles concentrated on showing a dialog as a glasspane to block user input and notifiy the user of some information.  In my case the upload was already in a dialog, so popping up another layered dialog on top of that would be ugly, so I wanted to find a way to display a loading indicator of some sort, in-line. 

The result is a JavaScript routine that can be called from  a clientListener which will either pop the glasspane and dialog if you point it to a dialog, otherwise it will display an inline component, such as an image with a spinning logo or some text.

The Script

 Here is the JavaScript, the first method showWhenBusy(), is the one called from the clientListener. It reads the ID of the component that we want to show/hide from an clientAttribute called loadingIndicatorId. This makes the code nice and generic as we've not had to hardcode component IDs. 

//Global variable to hold the component ref.
var loadingIndicatorComponent; 

function showWhenBusy(event) {
  //get the dialog or other component we want to show and hide
  var componentId = event.getSource().getProperty('loadingIndicatorId');
  loadingIndicatorComponent = AdfPage.PAGE.findComponent(componentId);
  if (loadingIndicatorComponent != null) {
  else {
    AdfLogger.LOGGER.logMessage(AdfLogger.SEVERE, "Requested indicator compoenent not found");

As you can see, all that this method does is to store the indicator component into a global JS variable and then create a busy state listener that the framework will invoke as it starts and ends the blocking operation.

The Listener

The listener is where all of the work happens. here we first of all check to see if the requested indicator component is a dialog or not, and then based on the busy state we do the right thing to show or hide.  In the case of the dialog this is a simple matter of calling the show() and hide() methods on the component.  In the case of any other component we achieve the effect by setting the CSS display style.  Note that in order to do this, we need to get a handle to the real DOM element that represents this component.  This is what the call to AdfAgent.AGENT.getElementById() call is doing:

function handleBusyStateCallback(event){
  if(loadingIndicatorComponent != null){
    // Check is this is a dialog as 
    // this needs different treatment
    var isDialog =
        (loadingIndicatorComponent.getComponentType() == "oracle.adf.RichPopup");

  if (event.isBusy()){     if (isDialog){;        }       else {       loadingIndicatorComponentId = AdfAgent.AGENT.getElementById(loadingIndicatorComponent.getClientId()); = "inherit";       }     }     else {     if (isDialog){       loadingIndicatorComponent.hide();       }       else {       loadingIndicatorComponentId = AdfAgent.AGENT.getElementById(loadingIndicatorComponent.getClientId()); = "none";       }

      AdfPage.PAGE.removeBusyStateListener(loadingIndicatorComponent, handleBusyState);     }  }    }

Wiring it up 

In order to call the script here we need to have a reference to it in the page. The normal place would be using an <af:resource> tag in the metaContainer facet of the document:

  <f:facet name="metaContainer">
    <af:resource type="javascript" source="/js/longRunningNotification.js"/>

Then the triggering component itself  uses a client listener to wire up the action and a clientAttribute to pass in the value of the required indicator component:

<af:commandButton text="Start Fong File Upload with Inline Message"
  <af:clientAttribute name="loadingIndicatorId"
  <af:clientListener method="showWhenBusy"

Notice that in this case, rather than passing a hardcoded ID through to the clientAttribute I'm calling a  backing bean getter (#{requestScope.uploadBB.loadingIndicatorId}). The idea of this is that we can ask the component itself for it's correct ID, reducing the margin for error. I have to give Frank the credit for this, it was his idea as we discussed this issue.

Set Up the Indicator Component 

For this to work, the component that I'm using as the indicator  needs a few attributes set:

  1. rendered and visible must be true
  2. clientComponent must be true 
  3. bindings must be set to associate the component with a reference in a backing bean
  4. If the component is not a dialog then we need to set it's initial display state to none so it will not be visible. This is done with inlineStyle.   

Here's a sample of a panelBox that we might use as the "busy" indicator: 

<af:panelBox text="Uploading your large file...." id="pb1"
 <af:panelGroupLayout id="pgl5" layout="horizontal">
    <af:spacer width="60" height="10" id="s1"/>
    <af:image source="/images/working.gif" id="i1"/>

Finally Wiring the ID 

The only missing bit now is how we get the ID of the component above into the clientAttribute that the JavaScript method is pulling. Recall that this was bound to the expression "uploadBB.loadingIndicatorId". So here's the implementation of that getter that lives in the page backing bean:

public String getLoadingIndicatorId() {
  return getLoadingBox().getClientId(FacesContext.getCurrentInstance());

I think that this nicely extends Frank's technique to open up a whole new range of UI possibilities when you're doing something that is going to take some time and want to keep the user entertained. 


Hawaii, Yes! Duncan has been around Oracle technology way too long but occasionally has interesting things to say. He works in the Development Tools Division at Oracle, but you guessed that right? In his spare time he contributes to the Hudson CI Server Project at Eclipse
Follow DuncanMills on Twitter

Note that comments on this blog are moderated so (1) There may be a delay before it gets published (2) I reserve the right to ignore silly questions and comment spam is not tolerated - it gets deleted so don't even bother, we all have better things to do with our lives.
However, don't be put off, I want to hear what you have to say!


« August 2016