Oracle Blog

Friday Nov 25, 2011

Sometimes ADF applications need to know about the user
browser type and version. For this, assuming you need this information in Java,
you can use the Trinidad RequestContext
object. You could also use the AdfFacesContext
object for the same, but since the ADF Faces Agent class is marked as deprecated, using the equivalent Trinidad classes is the better
choice.

Though apparently both approaches to the same thing, they
are different in the value they return and the condition under which they work.
The getId method, for example returns a session value as shown below

Though both seem to be identical, the difference is within "!1322120041091" added to the id
when reading it directly from the Http Session object. Dependent on the use
case the session Id is looked up for, the difference may not be important.

Another difference however, is of importance. The cookie reading
only works if the session Id is added as a cookie to the request, which is
configurable for applications in the weblogic-application.xml file. If cookies are disabled,
then the server adds the session ID to the request URL (actually it appends it
to the end of the URI, so right after the view Id reference). In this case
however no cookie is set so that the lookup returns empty. In both cases
however, the getId variant works.

Tuesday Nov 22, 2011

In ADF Faces, the command button is an instance of RichCommandButton and
can be created at runtime. While creating the button is not difficult at all,
adding behavior to it requires knowing about how to dynamically create and add
an action listener reference. The example
code below shows two methods: The first method, handleButtonPress is a public method exposed on a managed bean.

The second method is called in response to a user
interaction or on page load and dynamically creates and adds a command button. When
the button is pressed, the managed bean method – the action handler – defined above
is called. The action handler is referenced using EL in the created MethodExpression instance. If the
managed bean is in viewScope, backingBeanScope or pageFlowsScope, then you need
to add these scopes as a prefix to the EL (as you would when configuring the
managed bean reference at design time)

By default, the SelectionListener
property of an ADF bound tree points to the makeCurrent method of the
FacesCtrlHierBinding class in ADF to synchronize the current row in the ADF
binding layer with the selected tree node. To customize the selection behavior,
or just to read the selected node value in Java, you override the default
configuration with an EL string pointing to a managed bean method property. In
the following I show how you change the selection listener while preserving the
default ADF selection behavior.

To change the SelectionListener,
select the tree component in the Structure Window and open the Oracle
JDeveloper Property Inspector. From the context menu, select the Edit option to create a new listener method
in a new or an existing managed bean.

For this example, I created a new managed bean. On tree node select, the managed bean code prints the selected
tree node value(s)

//print first row attribute. Note that in a tree you have to
//determine the node type if you want to select node attributes //by name and not index String rowType = rw.getStructureDef().getDefName();
if(rowType.equalsIgnoreCase("DepartmentsView")){
System.out.println("This row is a department: " + rw.getAttribute("DepartmentId"));

Thursday Nov 17, 2011

In Oracle JDeveloper 11g R1, you set the display name of a train
stop of an ADF bounded task flow train model by using the Oracle JDeveloper
Structure Window.

To do so

Double-click
onto the bounded task flow configuration file (XML) located in the
Application Navigator so the task flow diagram open

In the task flow diagram, select the view activity
node for which you want to define the display name.

In the Structure Window., expand the view
activity node and then the train-stop node therein

Add the display name element by using the
right-click context menu on the train-stop node, selecting Insert inside train-stop > Display Name

Edit the Display Name value with the Property
Inspector

Following the steps outlined above, you can define static display
names – like "PF1" for page fragment 1 shown in the image below - for
train stops to show at runtime.

In the following, I explain how you can change the static
display string to a dynamic string that reads the display label from a resource
bundle so train stop labels can be internationalized.

There are different strategies available for managing
message bundles within an Oracle JDeveloper project. In this blog entry, I decided
to build and configure the default properties file as indicated by the projects
properties. To learn about the suggested file name and location, open the JDeveloper project properties (use a right mouse click on
the project node in the Application Navigator and choose Project Properties.

Select the Resource
Bundle node to see the suggested name and location for the default message
bundle. Note that this is the resource bundle that Oracle JDeveloper
would automatically create when you assign a text resource to an ADF Faces component
in a page.

For the train stop display name, we need to create the
message bundle manually as there is no context menu help available in Oracle JDeveloper. For this, use a right mouse click on the JDeveloper project
and choose New |
General | File from the menu
and in the opened dialog.

Specify the message bundle file name as the name looked up
before in the project properties Resource
Bundle option. Also, ensure that the file is saved in a directory structure that matches the package structure shown in the Resource
Bundle dialog. For example, you would save the properties file in the View
Project's src >
adf > sample directory if the package structure was "adf.sample" (adf.sample.ViewControllerBundle).

Edit the properties file and define key – values pairs for
the train stop component. In the sample, such key value pairs are

Next, select the display-name
element in the train stop node (similar to when creating the display name) and
use the Property Inspector to change the static display string to an EL expression
referencing the message bundle. For example:

#{messageBundle.TrainStop1}

At runtime, the train stops
now show display names read from a message bundle (the properties file).

Friday Oct 14, 2011

The af:document
component has a property InitialFocusId
that allows you to define the Id of an input component that should take focus
when a page initially loads. But how do you set the component focus for pages
that are already rendered? A use case for this is a partial submit that
executes logic on the server, after which the cursor focus in the UI needs to
be set to a specific input component of a page or page fragment. The solution
to this use case is JavaScript that is generated on the server and executed on
the client.

The simplified sample I wrote contains of three input text
fields and three command buttons. Initially, using the af:documentInitialFocusId property, the cursor focus is set to the first input
text field.

The command button send a partial submit to a managed bean
on the server. The managed bean reads the component Id of the input text field
to put the focus to from a client attribute that is defined on each command
button. Using the MyFaces Trinidad ExtendedRenderKitService class, the managed bean sends a
JavaScript call to the client to change the current component focus.

Important: By
default, ADF Faces does not render all its user interface components as
JavaScript objects. It only renders those components as JavaScript objects that
have behavior, like a table that can have its columns moved. Input text
components, for example, are rendered in HTML only, which means that the ADF
client side JavaScript framework will not find a handle to the component unless
you tell ADF Faces to create one. For this, you set the ClientComponent property of the input text fields to true. This also is required for the af:documentInitialFocusId property to work.

Below is the managed bean code that handles the command
button action and that composes and executes the JavaScript to set the client side
UI focus.

Friday Jul 08, 2011

In ADF Faces, to invoke a server side method in a managed
bean, you use the af:serverListener
tag. The af:serverListener
tag is added as a child to the component that owns the event and called from
JavaScript in a call to AdfCustomEvent.queue(
… )

In this example, the af:serverListener is added to a table
to notify a manage bean method about a double-click action.

Thursday Jul 07, 2011

In Oracle JDeveloper 11.1.2, a new client behavior tag af:checkUncommittedDataBehavior
is provided to check for uncommitted data when navigating away from a page
using a command button that has its immediate
property set to true. The tag can be applied as a child of any command
component, like

For the client behavior to work, you must set the document tag's uncommittedDataWarning attribute to on.

Just as a reminder: Client behavior tags in ADF Faces execute on the
client side. They are there to save you from writing JavaScript, thus
abstracting you from the complexity of the underlying client side APIs.

Wednesday Jun 08, 2011

One of the new features in Oracle JDeveloper 11.1.2 is the
ADF Faces Skin Editor for building pluggable application look and feels
declaratively. However, the ADF Faces Skin Editor is also available in a
stand-alone version for developers building skins for existing applications
built with previous versions of Oracle JDeveloper 11g and for web designers
that are tasked with building a look and feel but don't need the full Oracle
JDeveloper 11g installed.

The ADF Faces Skin Editor comes in a ZIP file that you
extract on your local machine. The parent folder the software unzips itself
into is called skineditor and
developers most likely feel attempted to change the folder name to include
additional information like the version number (11.1.2.0.0) or the vendor
(Oracle). However, an issue with the skin editor is that it requires the
parent folder name to be skineditor.
It only allows the writing to be in mixed case, but no change to the name
itself.

When changing the parent folder name, for example skineditor_11_1_2_00,
then, when starting the skin editor, the Splash Screen is shown but the editor itself
does not come up, though the process entry for the skineditor64W.exe is visible
in the Windows Task Manager.

Note that the reason for this behavior is that skineditor, which becomes the root folder of the software after unzipping it, is not considered to be the installation folder. The skineditor folder is considered to be part of the software and thus cannot be changed. To create a meaningful name for the folder hosting the skin editor software, unzip the software into an installation folder you create before. This can then have version numbers in it but must not have blanks in the naming.

Wednesday May 25, 2011

The af:exportCollectionListener
tag is a client behavior tag in ADF Faces. Client behavior tags implement
functionality that requires JavaScript on the client side if coded manually by
application developer. In fact, client behavior tags wrap the JavaScript that
is required for a solution and expose a JSF tag for declarative use instead. The
af:exportCollectionListener
exports the visible content of a collection, like exposed in an ADF
Faces table, to Excel. The tag is dragged on top of a command item, like a
toolbar button or a command button, and then configured with the table id for
which rows should be exported, the name of the file to produce, whether you
want to export all rows or just those that are selected, and an optional title
string. For more information, see the tag documentation:

When the command item that has the af:exportCollectionListener tag added is
invoked by a user, the tag is executed as well and produces the desired output.
However, applications usually are a lot more dynamic than to wait for a user to
press a button. Instead developers may want to invoke the client behavior
programmatically, which in case of a client behavior you can do using
JavaScript

The JavaScript code above looks an ADF Faces component up
in a search from the page root. The component is identified by its absolute
component Id ('pc1:ctb1' in the example as the button is in a toolbar facet of
a panel collection, which is a naming container). If the component is found,
the client event – AdfActionEvent – is queued for the button, which virtually
presses it.

However, what if you don't want JavaScript in your
application code? In this case, you can use Java to invoke JavaScript from a
managed bean. The following code sample provides a method that is called from
Java logic in your managed bean to composes the JavaScript String and to invoke
it on the client:

What you need to pay extra attention to is the ID of the
component ( a toolbar component in my example). If a component is within a
naming container like PageTemplate, Table, PanelCollection, Region, etc. then
the ID(s) of the surrounding naming containers must be added as a prefix to the
component ID. The form is namingContainerId:componentId.

Disadvantage of using JavaScript in Java: The script is harder
to debug on the client.

One more challenge!

Okay, now that I showed how to invoke a command item on a
client using JavaScript from Java, what if you don't want to have a button
showing in the UI? In this case, it should be the application logic only that
invokes the af:exportCollectionAtionListener.
In this case you still add a command item to the page but set its Visible property to false. This way the command item is
hidden in the user interface, but the functionality is still available for the
application to use.

Note: Don't
however try the same setting the "Rendered" property to false. If a
component is not rendered then it cannot be found and invoked on the client.

Tuesday Nov 30, 2010

A common development use case is to guide users when
working with input fields that require a specific input format. For example,
credit card and social security number fields use character delimiters that you
may want to enforce on a field. The following sample uses JavaScript to add a
defined delimiter character according to a defined character.

The American social security pattern is defined as xxx-xx-xxxx.
Users that type 123456789 should have the input automatically corrected to
123-45-6789 while they type. Also, the field should be protected from character
input and input length larger than the provided pattern.

With the above configuration, the handleNumberFormatConversion method is called for each key stroke
in the input field. Additional arguments provided to the function are the input
pattern and the character delimiter.

The JavaScript code that is addressed by the clientListener
on the InputText is shown below:

//
JavaScript function that applies a specific format // to numeric input. The
pattern argument defines the // input mask, e.g. xxx-xx-xxxx. The delimiter defines
// the delimiter character to add to the user input based // on the pattern

The sample is for number only input. However, changing it
for character or mixed input is not difficult to do. Note however that you
can't use this with af:inputDate component because this component doesn't work
well when setting String formatted values as the value property. (At least my debugging
showed this)