Browse Category by ADF

ADF: Different ways to display validation messages

This post is about the different ways that we have to display validation messages when, for example, an input component is marked as required or when other component such as af:validateDoubleRange is used to handle the validation.

We can have a simple form like this:

By default, if there is only one validation error, the validation message will be displayed like this:

But if we have more than one validation error, the messages will be displayed in a popup.

If we want to change the way those messages are displayed we can use a couple of components.
  • af:messages

 We have a couple of properties to configure.

    • globalOnly: When set to true, validation messages will not be displayed within this af:messages component.
    • inline: Whether the messages will be displayed in a popup or inline wherever this component is placed

We can add this component, for example, in the top of the form and whenever we get a validation error al messages will be displayed in that area.

  • af:message

 The second option is to add as many af:message as components we have so we can display validation errors inline next to the component that produces the error.

It doesn’t matter if we have 1 or more errors, all messages will be displayed inline, next to the component.

ADF 12.2.1: Publish and secure ADF Business Components as REST services

In ADF 12.2.1, released just before OOW, many new features were introduced, and one of them is to expose ADF Business Components as REST Web Services. You can check other ADF 12.2.1 features in my ADF 12.2.1 release post.
In this post I am going to publish and secure ADF BC as REST services.

The first thing we have to do is to configure a release version for REST. You can do this in adf.config.xml file.

In previous versions we could expose BC as SOAP web services in Application Module Web Services tab, and now we can choose also REST.
We can select the view instances and set a resource name.

A xml file will be automatically created where for example we can set the attributes we want to expose and also if we want to expose any custom methods that we have created in the view implementation classes.

A new project will be also created in our application RESTWebService. This is the project we have to deploy. Simply click on the project and click on run.

If we test the service with any client tool, for example, Postman, we can see that the service returns Departments data.

The next thing we are going to do is to secure the services. We have to configure ADF Security.

In the configuration wizard RESTWebService project must be selected.

After finishing the wizard we have to secure the resource by adding some roles or users.

The last step is to configure the rest URL pattern in web.xml file, under security tab.

Now we are ready to test. If we don’t set any authorization in the rest call we can see that a “401 – Unauthorized” is returned.

But if we configure HTTP basic authentication, Departments data is returned.

ADF: Filtering parent and child nodes in af:tree / af:treeTable

One of our customers required to filter data in a page with a tree component. Using Ashish’s post I am going to show you how to filter both parent and child nodes having just a single filter value. This can also be applied to treeTable component.

The first thing we need is a tree component and data structure, in this case we are going to use Oracle’s hr schema tables: Departments and Employees.

In our page we drag and drop DepartmentsView from datacontrols palette and create a tree component.

The next thing we have to do is to create a View Criteria in Departments View Object (parent).

We also have to crete a View Criteria in Employees View Object (child).

We have to expose setter method of the bind variable in parent View Object.
As we exposed the bind variable in parent, we need  to pass that value to the child by overriding createViewLinkAccessorRS method in parent View Object Implementation class (DepartmentsViewImpl.java)

The last step in the Model is to set a default View Criteria in parent View Object. To set it we have to right click on the View Object instance in our AppModule, click on ‘Edit’, select the View Criteria and click on ‘Ok’ button.

The Model is now finished, we now have to drag and drop the setter method from the data controls palette and create an ‘ADF Parameter Form’ so we can provide the filter value.

This will create ‘setsearchValue’ method binding in the pageDef. We also need to create a Execute operation of the parent View Object and call both operations from the ‘Filter’ button ActionListener.

This is how we should have the page.

If we run the application we can see the if we filter by ‘pat’ we just get values that contains that string.

If now we filter by ‘les’, we can see that we get values with ‘les’ string in both parent and child nodes.

ADF: Display Map values in af:table

When we want to populate an af:table programatically we usually use a collection based on a java bean (e.g. List<MyObject>) but in this post of JDeveloper & ADF the developer required to populate the table with Map values.
First we need to create a Map in our bean and add the values that we are going to show in the table.

If we try to populate the table we can see tat we need to know the keys of the Map to get the values.

As you can see Value Columns displays the value in the Map for ‘Key 1’ key, but using this method we can not dynamically display all values.

To solve this issue we need to create an array in our bean where we will have all keys of the Map.

Now that we have created in our bean all that we need, we can start building the table structure.

On the table of the second image we need to make some changes. First, instead of using Map property, we have to use the key array we have just created as value property of the table.

And, as we have to access Map values, we have to add an af:iterator inside the table and add the columns we need inside this iterator. The value property of this iterator is the Map property in the bean.

This way, to retrieve keys we are going to use #{row} and to retrieve values asociated to a key we are going to use #{var[row]}.

Oce we have finished with the changes, if we run the application we can see that all the values of the Map are displayed in the table without the need of knowing the keys of the Map.

ADF: Switching between skins on runtime based on the url

Andrejus posted a couple of months ago how to switch between alta and skyros in ADF 12c. This is a cool way to start the migration from 11g to 12c and Alta UI. I am going to show you another way to use one skin or other based on the page you are.

Firstly we have to create a bean and a property inside it where we are going to store the current skin. We have to set this bean as sessionBean.

After that we have to set a bean property in skin-family in our trinidad-config so we can set the skin dynamicaly.

The next step is to create a filter. In doFilter we are going to evaluate the URL and set the skin based on that value. We also have to instantiate the bean and add it to sessionScope becasuse the first time it will be null.

Once we have the filter created we have to add it to web.xml

Now that we have all setup, having multiple pages, if we test it we can see that the the page “alta” will display AltaUI skin and “skyros” page wil dispklay Skyros skin,