Jdev 12c: Implementing SQL IN Clause in an ADF ViewObject Query or ViewCriteria (Part 2)

In part one, showed how to implement a SQL IN clause in ADF. Now I show how to use this technique in a ViewCriteria or directly in a query of a view object.

We have to solve a couple of problems before we can really use the technique from part one in a ViewCriteria. As you know, when using a ViewCriteria, you select an operator which in turn is translated into SQL code. So, we have to find a way to create a new operator which will then be used to create the needed SQL code.

The technique to do this comes from an older post. Please look at Extending ViewCriteria to use SQL CONTAINS where I showed the basics on how to do this. The older post was designed for JDeveloper 11.1.2.1.0. Using the current JDeveloper version 12.2.1.3 give some ways for improvement of the earlier code.

The first improvement is that JDeveloper 12.2.1.3 allows us to introduce custom operators to view criteria. In the older sample, I had to use the description field of the ViewCriteria to pass information which SQL to generate. Now we can define an operator named ‘IN’ and use it in the ViewCriteria like any other default operator.

The next problem is how to generate the SQL shown in part one when the new custom operator ‘IN’ should be used. One of the big advantages of ADF is reusability. We use a base class which extends from ViewObjectImpl and use this new base class in the project.

The base class is named BaseViewObjectForSqlInClause were we implement the needed method

public String getCriteriaItemClause(ViewCriteriaItem aVCI)

which gets called for each part or item of a ViewCriteria. See the code of hte base class below.

Base Class

public class BaseViewObjectForSqlInClause extends ViewObjectImpl {
    private static ADFLogger _logger = ADFLogger.createADFLogger(BaseViewObjectForSqlInClause.class);

    // comma-separated list of custom operators. Each custom operator muast have a ',' at the end as delimeter!
    private static final String CUSTOM_OPERATORS = "IN,";

    public BaseViewObjectForSqlInClause(String string, ViewDefImpl viewDefImpl) {
        super(string, viewDefImpl);
    }

    public BaseViewObjectForSqlInClause() {
        super();
    }

    /**
     * Check if a given criteria item tries to use an 'IN' operator using a bind parameter (comma seperated list of strings).
     * Create special SQL clause for 'IN' operator
     * @param aVCI Criteria item
     * @return where clause part for the criteria item
     */
    @Override
    public String getCriteriaItemClause(ViewCriteriaItem aVCI) {
        // we only handle the SQL 'IN' operator
        String sqloperator = aVCI.getOperator();
        // add comma to operator as delimiter
        boolean customOp = CUSTOM_OPERATORS.indexOf(sqloperator.concat(",")) >= 0;
        customOp |= sqloperator.indexOf("NVL") >= 0;
        if (customOp) {
            ArrayList<ViewCriteriaItemValue&gt; lArrayList = aVCI.getValues();
            if (lArrayList != null &amp;&amp; !lArrayList.isEmpty()) {
                // check if the criteria item has bind parameters (only the first if of interest here as the IN clause onlyallows one parameter)
                ViewCriteriaItemValue itemValue = (ViewCriteriaItemValue) lArrayList.get(0);
                if (itemValue.getIsBindVar()) {
                    // get variable and check if null values should be ignored for bind parameters
                    Variable lBindVariable = itemValue.getBindVariable();
                    Object obj = ensureVariableManager().getVariableValue(lBindVariable.getName());
                    boolean b = aVCI.isGenerateIsNullClauseForBindVariables();
                    if (b &amp;&amp; obj == null) {
                        // if null values for bind variables should be ignored, use the default getCriteriaItemClause
                        return super.getCriteriaItemClause(aVCI);
                    }

                    try {
                        // we only handle strings data types for bind variables
                        String val = (String) obj;
                    } catch (Exception e) {
                        // the bind variabel has the wrong type! Only Strings are allowed
                        _logger.warning("Bind variabel for SQL " + sqloperator +
                                        " clause is not of type String! -&gt; No custom SQL clause created! (Class: " +
                                        obj.getClass() + ", Content: " + obj + ", Variable: " +
                                        lBindVariable.getName() + ", View: " + this.getName() + ")");
                        String s = ":" + lBindVariable.getName() + " = :" + lBindVariable.getName();
                        return s;
                    }

                    // only handle queries send to the db
                    if (aVCI.getViewCriteria()
                            .getRootViewCriteria()
                            .isCriteriaForQuery()) {
                        String sql_clause = null;
                        switch (sqloperator) {
                        case "IN":
                            sql_clause = createINClause(aVCI, lBindVariable);
                            break;
                        default:
                            _logger.severe("Unknown custom operator '" + sqloperator + "' found! -&gt; do nothing!");
                            break;
                        }

                        return sql_clause;
                    } else {
                        // bind variable not set or
                        // for in memory we don't need to anything so just return '1=1'
                        return "1=1";
                    }
                }
            }
        }

        return super.getCriteriaItemClause(aVCI);
    }

    private String createINClause(ViewCriteriaItem aVCI, Variable lBindVariable) {
        // start build the sql 'IN' where clause (COLUMN is the name of the column, bindParam the name of the bind variable):
        // COLUMN IN (SELECT regexp_substr(:bindParam,'[^,]+',1,level) FROM dual CONNECT BY regexp_substr(:bindParam,'[^,]+',1,level) IS NOT NULL
        // get flagg to create an sql where clause which ignores the case of the bind parameter
        boolean upper = aVCI.isUpperColumns();
        String sql_in_clause = null;
        StringBuilder sql = new StringBuilder();
        if (upper) {
            sql.append("UPPER(");
        }
        sql.append(aVCI.getColumnNameForQuery());
        if (upper) {
            sql.append(")");
        }
        sql.append(" ").append(aVCI.getOperator());
        sql.append(" (select regexp_substr(");
        if (upper) {
            sql.append("UPPER(");
        }
        sql.append(":");
        sql.append(lBindVariable.getName());
        if (upper) {
            sql.append(")");
        }
        sql.append(",'[^,]+', 1, level) from dual connect by regexp_substr(");
        if (upper) {
            sql.append("UPPER(");
        }
        sql.append(":").append(lBindVariable.getName());
        if (upper) {
            sql.append(")");
        }
        sql.append(", '[^,]+', 1, level) is not null)");
        sql_in_clause = sql.toString();

        _logger.finest("generated SQL-IN clause: " + sql_in_clause);

        return sql_in_clause;
    }
}

Using Base Class in Project

To use the base class in all new created ViewObjects of the project, we change the models project properties

Now, whenever you create a new ViewObject, the new base class is used and the SQL IN operator can be used in the VOs view criteria.

You can change any existing ViewObject to use the BaseViewObjectForSqlInClause by changing the extends clause in the class definition by hand.

Creating a ViewCriteria Using the Custom IN Operator

All pieces are in place and using the IN operator is pretty easy. We start by creating a new ViewObject named EmployeesOfDepartmentsViewCriteria

Now we have a ViewObject based on an EntityObject for the Employees. We need to make one change. The DepartmentId is an Integer type attribute, the comma-separated list is of type String (containing numbers). This doesn’t match. We add another attribute to the ViewObject of type String which we calculate from the DepartmentId Integer attribute. We change the SQL query for this by selecting the ‘Query’ node first unselecting the checkbox ‘Calculate Department Query at Runtime (recommended)’, second select the checkbox ‘Write Custom SQL’ and third add the line ‘to_char(Employees.DEPARTMENT_ID) DEPARTMENT_ID_STR,’ to the query.

Once this new ViewObject has been created, we add a ViewCriteria to it

If you like, you can turn off the checkbox ‘Ignore Case’ as it is not needed. The numbers are always lower case.

Running the ApplicationModule in the Tester

At this stage, we can test run the application module in the Application Module Tester (see JDeveloper & ADF: Use the Application Module Tester (BC4J Tester) to Test all your BusinessLogic).

Click the binocular button to select the ViewCriteria we created and click ‘Find’

Which will open a dialog asking for the value of the bind variable

Clicking ‘OK’ will show the result as

Running the ViewCriteria on a Page

Finally, we can add the ViewCriteria to a page as af:query and test it there. I’ll spare the exact howto here and just show hte running application.

Or with different parameters and spaces

You can download the sample application from GitHub BlogSqlInClause.

The Sample was built using JDeveloper 12.2.1.3 (but it should work in all 12c versions) and uses the HR DB schema.

Advertisements

JDev 12.2.1.3: Multi select component table filter

In this blog article, I show how to use a multi-select component as a filter in a table. The sample is based on an older sample from Frank Nimphius (98. How-to use multi select components in table filters). The sample was built for JDev 11g R1 and R2.

It works using 12c too, but you get deprecation warnings after the migration. A user on the JDeveloper & ADF forum asked if I could provide a sample running in 12c without the deprecation warnings.

I will only show how to rewrite the bean method which is called when the user enters one or more values in the filter. The remaining part of the original sample works without a change in 12c.

To better understand what I’m talking about I show some images from the original blog:

The image above shows the sample table. Below we see the multi-select component to filter for multiple departments:

Please read the original blog entry to understand how to build the UI. The remaining part of this blog covers how to build the custom query listener method.

Custom Query Listener

In the original sample the two methods

...
Map _criteriaMap = fqd.getFilterCriteria();
...
fqd.setFilterCriteria(_criteriaMap);

are used which produce deprecation warnings in 12c

Starting from JDev 12.1.3 you can’t use the criteriaMap from the FilterableQueryDescriptor. Instead, you have to first get the ConjunctionCriterion from the FilterableQueryDescriptor and get the map of Criterion from it. The map holds the filter criteria entered by the user.

As you don’t use the criteria directly, you can’t set it back after generating the filter fro the multi-select. You work with the Criterion instead.

The new Method looks like

    /**
     * Custom Query Listener.
     * Applies af:selectMany choice values to the table filter criterion
     * @param queryEvent
     */
    public void onEmployeeTableQuery(QueryEvent queryEvent) {
        //user selected values
        ArrayList<Object&gt; departmentIdArray = null;
        FilterableQueryDescriptor fqd = (FilterableQueryDescriptor) queryEvent.getDescriptor();

        //current criteria
        ConjunctionCriterion conjunctionCriterion = fqd.getFilterConjunctionCriterion();
        Map<String, Criterion&gt; criterionMap = conjunctionCriterion.getCriterionMap();
        Criterion criterion = criterionMap.get("DepartmentId");

        //Translate DepartmentId array list to OR separate list of values
        StringBuffer deptIdFilterString = new StringBuffer();
        AttributeCriterion adfcriterion = null;
        // flag we set only if the DepartmentId filter is set (to reset the selection later)
        boolean flagDepIdFilter = false;
        if (criterion != null) {
            adfcriterion = (AttributeCriterion) criterion;
            Object object = adfcriterion.getValue();
            if (object != null) {
                flagDepIdFilter = true;
                departmentIdArray = (ArrayList<Object&gt;) object;

                for (int argIndex = 0; argIndex < departmentIdArray.size(); argIndex++) {

                    //You need to know what is the underlying data type you are dealing
                    //with for the attribute. If you are on 11gR1 (11.1.1.x) then this
                    //type is jbo.domain.Number for numeric attributes.
                    //
                    //If you are on 11g R2 (11.1.2.x) this could be oracle.jbo.domain.Number,
                    //Integer or BigDecimal. If you use 11g R2, check the View Object for the
                    //attribute data type

                    if (argIndex == 0) {
                        //first argument has no OR

                        //this sample used oracle.jbo.domain.Number for the
                        //DepartmentId attribute
                        Number departmentId = (Number) departmentIdArray.get(argIndex);
                        deptIdFilterString.append(departmentId.toString());
                    } else {
                        //any subsequent argument is OR'ed together
                        deptIdFilterString.append(" OR ");
                        Number departmentId = (Number) departmentIdArray.get(argIndex);
                        deptIdFilterString.append(departmentId.toString());
                    }
                }
                //for some reasons, if in a single value select case, the
                //filter breaks and an error message is printed that the
                //String representation of the single value isn't found in
                //the list. The line below fixes the problem for filter values
                //that are positive numbers
                deptIdFilterString.append(" OR -1");
                String departmentIds = deptIdFilterString.toString();
                adfcriterion.setValue(departmentIds);
                fqd.setCurrentCriterion(adfcriterion);
            }
        }


        // preserve default query listener behavior
        //#{bindings.allEmployeesQuery.processQuery}

        FacesContext fctx = FacesContext.getCurrentInstance();
        Application application = fctx.getApplication();
        ExpressionFactory expressionFactory = application.getExpressionFactory();
        ELContext elctx = fctx.getELContext();

        MethodExpression methodExpression =
            expressionFactory.createMethodExpression(elctx, "#{bindings.allEmployeesQuery.processQuery}", Object.class,
                                                     new Class[] { QueryEvent.class });
        methodExpression.invoke(elctx, new Object[] { queryEvent });

        //restore filter selection done by the user. Note that this
        //needs to be saved as an ArrayList
        if (flagDepIdFilter) {
            adfcriterion.setValue(departmentIdArray);
            fqd.setCurrentCriterion(adfcriterion);
        }
    }

From the FilterableQueryDescriptor we get the ConjunctionCriterion and from this the map of Criterion. This map holds all filter values entered by the user in the filter of the table. We retrieve the one for the ‘DepartmentId’ and check if the value for it is not null. In this case, the criterion holds an array of the selected DepartmentId. From this array, we build a new string where we use the ‘OR’ operator to concatenate the array values.

Once this string is built, we set it back to the Criterion and execute the original query listener

You can download the sample from GtHubBlogMultiSelectComponentFilterTable for inspection and/or testing. The sample was built using JDev 12.2.1.3 and uses the HR DB schema.

JDeveloper: executeWithParams Problem: bind variable setters are not called

In one of my current bigger ADF projects (yes, there are still big ADF projects!) I had a problem with the ‘executeWithParams’ operation binding called from a bean. To understand the problem I first give a brief description.

Problem

We have a special string column in some of our VOs. For this column, there is a bind parameter which is added to the where clause of the VO. Getter and setter for this bind parameters are generated to be able to set this parameter safely. In the setter method, some checks are done and special formatting is applied to the passed value.

Now we used the VOs executeWithParams operation to create a search form. Hitting the button to execute the query gave us a wrong result. As it turned out, that the execWithParams operation passes the parameters to the VO but it doesn’t use the getter/setter methods for the parameter. The parameters are directly set into the slots by the VariableManager.

Solutions

We want to transform or convert the given parameter right in the query. This way the developer doesn’t need to think about or to remember that there should be a transformation of the parameter. A central solution is preferred. Two solutions come to mind.

Expose a method in the VO

One solution would be to create a method in the VO and expose this method in the client interface of the VO. Then this method is visible in the binding layer and you can use call the method instead of using executeWithParams.

This works OK, but if a developer uses the executeWithParams method, you’ll still don’t get the right result.

Change the behavior of the executeWithParams method

I looked for a direct hook into the executeWithParams method but did not find one 😦

However, it turned out that the executeWithParam method calls the executeQuery method of the VO. At this point, the parameters are all set. This is done in the background via the VariableManager used in VOs to keep track of the bind parameters and their different type. There are where clause parameters and parameters used in view criteria. The latter are handled differently but this is not essential for this solution. All we need to know is that the parameters are correctly set when the executeQuery method is called.

The solution is to overwrite the executeQuery method of the view object (or use a base class) and check the parameters before executing the query.

Implementing the solution

In an earlier blog “Dump VO query and it’s parameter with their values” I showed how to get to the parameters defined for a VO and dump their values. Instead of writing the values to the log file, we look for the parameter, change the value, if one is given and then execute the query with the now converted parameter.

I use reflection to check if a setter method for a parameter is defined in the VO. If this is the case, I call the setter with the value set by the user. This way the setter is called when the query is called via the executeWithParams method. The code to change the parameter has only to be written once in the setter.

Below is the code:

    @Override
    public void executeQuery() {
        _logger.info("executeQuery");
        transformHistoryParameter();
        dumpQueryAndParameters();
        super.executeQuery();
    }

    private void transformHistoryParameter() {
        VariableValueManager vm = ensureVariableManager();
        Variable[] variables = vm.getVariables();
        // check each parameter for this query
        for (Variable var : variables) {
            String varName = var.getName();
            try {
                String mName = "set" + varName;
                Class mvarType = var.getJavaType();
                Method m = this.getClass().getMethod(mName, new Class[] { mvarType });
                // check if method is a setter method
                if (isSetter(m)) {
                    Object val = vm.getVariableValue(var);
                    m.invoke(this, val);
                }
            } catch (NoSuchMethodException e) {
                // nothing to do if there is no setter defined
                return;
            } catch (IllegalAccessException | InvocationTargetException e) {
                // nothing to do if there is no setter defined
                return;
            }
        }
    }

    public boolean isGetter(Method method) {
        if (!method.getName().startsWith("get")) {
            return false;
        }
        if (method.getParameterTypes().length != 0) {
            return false;
        }
        if (void.class.equals(method.getReturnType())) {
            return false;
        }
        return true;
    }

    public boolean isSetter(Method method) {
        if (!method.getName().startsWith("set")) {
            return false;
        }
        if (method.getParameterTypes().length != 1) {
            return false;
        }
        return true;
    }

    public void dumpQueryAndParameters() {
        // get the query in it's current state
        String lQuery = getQuery();
        // Dump query
        _logger.info("---query--- " + lQuery);
        //get Valriables
        AttributeList attributeList = getNamedWhereClauseParams();
        String[] attributeNames = attributeList.getAttributeNames();
        if (attributeNames == null || attributeNames.length == 0) {
            _logger.info("--- No variables found");
        } else {
            _logger.info("---Variables:");
            for (int ii = 0; ii < attributeNames.length; ii++) {
                Object lObject = attributeList.getAttribute(ii);
                _logger.info("  --- Name: " + attributeNames[ii] + " Value: " +
                             (lObject != null ? lObject.toString() : "null"));
            }
        }
    }

Sample

The sample to see the code at work can be downloaded from GitHub BlogExecuteWithParamsProblem

It was implemented using JDeveloper 12.2.1.3 and the HR DB schema.

To make it easy, I used the HR DB schema and built a query on the EMPLOYEES table:

A forth bind variable is introduced in a view criteria

The transformation uses the pMail bind parameter and makes it uppercase.

    /**
     * Returns the bind variable value for pMail.
     * @return bind variable value for pMail
     */
    public String getpMail() {
        String val = (String) getNamedWhereClauseParam("pMail");
        _logger.info("value: " + val);
        return val;
    }

    /**
     * Sets <code>value</code> for bind variable pMail.
     * @param value value to bind as pMail
     */
    public void setpMail(String value) {
        _logger.info("value:" + value);
        String newVal = value;
        if (value != null) {
            newVal = value.toUpperCase();
            _logger.info("Value transformed to " + newVal);
        }
        setNamedWhereClauseParam("pMail", newVal);
    }

I know that it would be easy to without this code by just setting the ‘ignore case’ flag when defining the query, but this is just a sample of a change of a parameter.

The data model in the application module looks like

As you see I added a second instance of the EmployeesView and attached the view criteria to this instance. Running the application module in the tester (see JDeveloper & ADF: Use the Application Module Tester (BC4J Tester) to Test all your BusinessLogic)

We get

And the following log

Feb 08, 2019 3:05:38 PM de.hahn.blog.execwithparams.model.EmployeesViewImpl executeQuery
INFO: executeQuery
Feb 08, 2019 3:05:38 PM de.hahn.blog.execwithparams.model.EmployeesViewImpl setpMail
INFO: value:ski
Feb 08, 2019 3:05:38 PM de.hahn.blog.execwithparams.model.EmployeesViewImpl setpMail
INFO: Value transformed to SKI

Feb 08, 2019 3:05:38 PM de.hahn.blog.execwithparams.model.EmployeesViewImpl setpName
INFO: value: null
Feb 08, 2019 3:05:38 PM de.hahn.blog.execwithparams.model.EmployeesViewImpl setpDate
INFO: value: null
Feb 08, 2019 3:05:38 PM de.hahn.blog.execwithparams.model.EmployeesViewImpl dumpQueryAndParameters
INFO: —query— SELECT Employees.EMPLOYEE_ID, Employees.FIRST_NAME, Employees.LAST_NAME, Employees.EMAIL, Employees.PHONE_NUMBER, Employees.HIRE_DATE, Employees.JOB_ID, Employees.SALARY, Employees.COMMISSION_PCT, Employees.MANAGER_ID, Employees.DEPARTMENT_ID FROM EMPLOYEES Employees WHERE ( ( ( ( Employees.LAST_NAME LIKE ( :pName || ‘%’) ) OR ( :pName IS NULL ) ) AND ( ( Employees.EMAIL LIKE ( :pMail || ‘%’) ) OR ( :pMail IS NULL ) ) AND ( ( Employees.HIRE_DATE >= :pDate ) OR ( :pDate IS NULL ) ) ) )
Feb 08, 2019 3:05:38 PM de.hahn.blog.execwithparams.model.EmployeesViewImpl dumpQueryAndParameters
INFO: —Variables:
Feb 08, 2019 3:05:38 PM de.hahn.blog.execwithparams.model.EmployeesViewImpl dumpQueryAndParameters
INFO: — Name: pMail Value: SK
I
Feb 08, 2019 3:05:38 PM de.hahn.blog.execwithparams.model.EmployeesViewImpl dumpQueryAndParameters
INFO: — Name: pName Value: null
Feb 08, 2019 3:05:38 PM de.hahn.blog.execwithparams.model.EmployeesViewImpl dumpQueryAndParameters
INFO: — Name: pDate Value: null
Feb 08, 2019 3:05:38 PM de.hahn.blog.execwithparams.model.EmployeesViewImpl dumpQueryAndParameters
INFO: — Name: pSalary Value: null

We see, that executeQuery() is called, then setpMail is called and the value given in the UI is converted to uppercase. In the dump of the query, we see that the uppercase parameter is used for the query.

The same works with the other view object in the application module. Just try it out yourself. The sample has a small UI project allowing you to test it in the browser too.

JDeveloper: Creating a FULL OUTER JOIN View Object

On my todo list, I found a topic which I wanted to blog about for a long time. The problem is how to create a ViewObject, based on EntityObjects, which builds a full outer join between two tables.

For those of you who don’t know about full outer joins in SQL here is a short description from https://www.w3schools.com/sql/sql_join_full.asp:

The FULL OUTER JOIN keyword return all records when there is a match in either left (table1) or right (table2) table records.

Note: FULL OUTER JOIN can potentially return very large result-sets!

FULL OUTER JOIN Syntax:

SELECT column_name(s)
FROM table1
FULL OUTER JOIN table2 ON table1.column_name = table2.column_name;
Image to visualize a full outer join

There are not too many use cases where you need to use a full outer join, but they exist (e.g. https://searchoracle.techtarget.com/answer/Another-good-FULL-OUTER-JOIN-example or to compare two or more tables).

Problem: How can a full outer join be created in ADFbc?

I show how to create a VO based on Employees and Department EO using a full outer join on the department_id. This VO will return all departments with all their employees, departments which don’t have any employee and all employees who don’t have a department.

Following the syntax from above, we use an SQL statement like

SELECT Departments.DEPARTMENT_ID,
  Departments.DEPARTMENT_NAME,
  Employees.DEPARTMENT_ID AS DEPARTMENT_ID1,
  Employees.LAST_NAME,
  Employees.FIRST_NAME,
  Employees.EMPLOYEE_ID
  FROM DEPARTMENTS Departments
FULL OUTER JOIN EMPLOYEES Employees
ON Departments.department_id = Employees.department_id
ORDER BY Departments.department_id, Employees.last_name;

There are other SQL statements which produce the same result like

SELECT DISTINCT * FROM
  (SELECT d.department_id AS d_dept_id,
     d.DEPARTMENT_NAME,
     e.department_id AS e_dept_id,
     e.last_name last_name,
     e.FIRST_NAME
   FROM departments d
   LEFT OUTER JOIN employees e
   ON d.department_id = e.department_id
   UNION ALL
   SELECT d.department_id AS d_dept_id,
     d.DEPARTMENT_NAME,
     e.department_id AS e_dept_id,
     e.last_name,
     e.FIRST_NAME
   FROM departments d
   RIGHT OUTER JOIN employees e
   ON d.department_id = e.department_id
  )
ORDER BY d_dept_id, last_name;

The statement combines a left outer join with a right outer join. The ‘Select distinct….’ is used to eliminate duplicate rows which are returned for both joins. Anyway, the results are equal.

Solution

Now we can build the view object based on the two entity objects (Departments and Employees). We start by creating a new view object

and fill in the name as ‘DepEmpViewObj’. Make sure you select ‘Entity’ as ‘Data Source’

On the next wizard page shuttle the Departments and the Employees entities to the right

Now select the Departments entity and you get

Selecting the Employees entity you get

This we have to change as the join type is ‘inner join’ and not what we like to do. If you select the drop down menu you see

Hm, there is no ‘full outer join’ as joint type. We can’t create this type of join declaratively, we have to do this directly with a SQL statement. So, drop down the ‘Association’ field and select ‘none’

The final definition is

On the next page select the attributes

We don’t change anything in step 4 so we go to step 5. Here uncheck the ‘Calculate…’ checkbox and select the ‘Write Custom SQL’

Now we copy the SQL statement from above and copy it into the text area after deleting the current statement. Don’t forget to delete the ‘order by…’ part from the ‘Select:’ text area and add them into the ‘Order By:’ text field

We skip the steps 6,7 and 8 and add the view object to the application module in step 9

Finally, we finish the wizard and are ready to test the view object.

Running solution

Running the application module in the tester show the resulting table (only the last ~40 rows are shown)

We see departments without employees and we have one employee (see the last row) without an assigned department. All as expected.

To complete the application we add the new DepEmpViewObj onto a page as a table. Running it we get the same result as in the tester.

You can download the sample from GitHub BlogFullOuterJoin. The sample was built using JDeveloper 12.2.1.3 and uses the HR DB. The same technique can be used with other JDeveloper versions too.

JDeveloper 12.2.1.3: REST POST Sample

Lately, I got a request to build a REST POST sample using an ADF REST DataControl. Well, here we go.

First of all, we need a REST API which allows us to create data as this will be translated to REST POST call. I deliberately don’t want to use an ADF based REST service as there are samples available for this.

Looking for free REST API services which allow creating data I found “reqres’ (http://reqres.in), a free ‘hosted REST-API ready to respond to your AJAX requests’. This service can be used to test REST calls using any verb you like. It promises to be online 24/7.

Let’s start by creating a new ADF Web Application. If we would only test the REST service we could have created a custom application, but I want to show the viewController part too, so the ADF Web Application is just fine.

I don’t show how to do this here as you can see it done here ‘Why and how to write reproducible test cases’

As we don’t use the ADFModel project you can delete this empty project if you like. After creating the initial workspace, we create a new project from the gallery as a ‘Custom Project’

I named the new project ‘BRPWebService’, but you can name the project anything you like. Inside the new project we new create a ‘Web Service Data Control (SOAP/REST)’:

After selecting this, a wizard will ask which kind of ‘Web Service Data Control’ we like to create. We choose REST and now have to specify the base URL to the REST service API.

We skip the next page as there is no OWSM Policy needed to access the REST API

In step 3 we define the path we want to use after the base URL. From the web page of the service, we see a bunch of possible API endpoints.

For this test, we use the ‘api/users’ path. The whole URL now is ‘http://reqres.in/api/users’. To test the creation of data we use the POST verb, so we select the POST. To make sure the service is functional, we add the GET verb too.

After naming the methods getUsers for the GET and createUser for the POST, we need to give the wizard info about the parameters the API expects and the response we get when the call is successful. When we click on the GET verb on the web page, we get all the info we need.

All JSON code samples are available from the web page or from this blog in the appendix

We copy the response from the web page and pate it o the ‘Response Sample’ field and create a parameter ‘page’ in the parameter section of the next wizard step.

The same we do for the createUser method. Here we have to copy the request parameter JSON and the response JSON from the web page.

On the next page, we test the Web Service Data Control

This completes the creation process. We can now run the Datacontrol from inside JDeveloper by right-clicking the data control and choosing ‘Run’

Testing the getUsers method with the parameter set to 2 we receive the right answer

Now, let’s try the POST verb by trying out the createUser method. As a parameter, we pass some JSON and after executing the method we get a JSON part back telling us the new Id of the user.

Everything works. Please remember that we only use a ‘fake’ service which accepts our JSON, but will not add any data!

Sample Application

For the fun of it, I developed a ViewControler which uses the REST Data Control. It allows to ask for users by providing a page to load, or you can test the POST verb to create a ‘fake’ new user.

The final application can be downloaded from GitHub BlogRestPost. It was built using JDeveloper 12.2.1.3 without a DB connection.

After starting the app we see this UI

The service allows getting users in page mode, three users per page. So, enter 3 into the ‘Page’ filed and we get

Now, filling ‘name’ and ‘job’ field and clicking the createUser button we get

The service returns a new user with a new ID and the timestamp when the user was created.

Appendix

JSON reponse for GET api/users?page=2

{
    "page": 2,
    "per_page": 3,
    "total": 12,
    "total_pages": 4,
    "data": [
        {
            "id": 4,
            "first_name": "Eve",
            "last_name": "Holt",
            "avatar": "https://s3.amazonaws.com/uifaces/faces/twitter/marcoramires/128.jpg"
        },
        {
            "id": 5,
            "first_name": "Charles",
            "last_name": "Morris",
            "avatar": "https://s3.amazonaws.com/uifaces/faces/twitter/stephenmoon/128.jpg"
        },
        {
            "id": 6,
            "first_name": "Tracey",
            "last_name": "Ramos",
            "avatar": "https://s3.amazonaws.com/uifaces/faces/twitter/bigmancho/128.jpg"
        }
    ]
}

JSON payload and response for POST api/create

Payload
{
    "name": "morpheus",
    "job": "leader"
}

Reponse
{
    "name": "morpheus",
    "job": "leader",
    "id": "783",
    "createdAt": "2018-11-19T21:42:47.556Z"
}

JDeveloper: Task Flow with optional Parameters

In one of my current projects, I came across a wired problem concerning a task flow which uses parameters to configure the flow. To make it simple to understand the problem I made up a fictive use case.

Use Case

This is not a real use case, but an abbreviation of it just to show the problem and how to resolve it. It might not make sense in real life, but it allows to show the problem.

We like to see a form to enter some data. One of the fields the user can enter should be used to select a specific layout of the following pages. Ony Layout should be horizontal and one should be vertical.

The layout should allow showing a title with a number, a text part, and a footer part. Each of the parts is optional, only the layout must be specified.

The flow can be used at different points in different flows in the application.

Implementation

The implementation is easy. We build a task flow, build with pages, and add 5 parameters to it. This task flow looks like this:

In a router component, we check the required parameter to decide which layout to use. The ‘none’ page is used if the parameter is not ‘v’ or ‘h’.

For the layout pages, which implement the layout part, I used a af:panelGridLayout with the right number of rows and columns. Here is the vertical.jsf page

Or the source view

The other pages can be found in the sample which was built using JDeveloper 12.2.1.3. You can download the sample using the link at the end of the blog.

Now that we have the reusable task flow we need another task flow (adfc-config.xml in this case) to show how to use the use of the task flow.

We see an index page which calls the task flow using three different navigations (toPageNoParam, toPageAllParam and toPageTextOnly). The difference between the navigations are the parameters set to the task flows.

Here they are

Running the application we get the following output after filling in the form on the index page

WAIT, this doesn’t look right. The page with text only parameters displays the text in the footer section instead of the text section. If we look at the parameters defined for this task flow call we see

Yes, we added the value to the wrong parameter, ‘footer’ instead of ‘text’!

Easy change, we copy move it over to the ‘text’ parameter using copy and paste:

And we get

Great, this looks like it should be.

Problem(s)

WAIT again, in the log window we now get an error message

<oracle.adf.model> <ValueMappingXmlImpl> <parse> 
   <ADFc: /WEB-INF/adfc-config.xml: Failed to parse element input-parameter: null value found for value.>

Why’s that?

If you look closely at the parameters, you’ll notice, that the ‘footer’ value is empty, whereas the other not set values showing a ‘-’. So we add the ‘-’ to the footer parameter:

To get this output running the app:

The error message in the log window is gone 🙂

Hm, but now we see the ‘-’ for the footer value. The value for the ‘title’ parameter looks identical to the parameter ‘footer’. However, we don’t see the ‘-’ for the ‘title’ in GUI.

Solution

Looking at the XML of the task flow call shows:

Now the problem is, that JDeveloper shows a ‘-’ for a parameter which is not set in the XML representation, meaning that the parameter is not in the XML structure at all!

The ‘-’ we typed into the ‘footer’ parameter is visible as value for the parameter and thus it printed when running the application.

The final solution is to remove the ‘footer’ parameter from the XML structure:

This will get us the following display in JDeveloper

The resulting running page now looks like

And we don’t see the error message in the log.

Sample Download

You can download the final application from GitHub BlogTaskFlowParameter. The sample was built using JDeveloper 12.2.1.3.0 and doesn’t need a DB connection.

ADF TreeTable Advanced Sample

Building a tree table isn’t straightforward if you want an appealing design. By design, I don’t mean something fancy with different fonts or colors, but I’m talking about the definition of the tree and its sub-notes.

Look at an af:treetable which is generated automatically for you using the Departments and Employees tables of the HR DB.

<af:treeTable value="#{bindings.DepartmentsView1.treeModel}" var="node"
              selectionListener="#{bindings.DepartmentsView1.treeModel.makeCurrent}"
              rowSelection="single" id="tt1">
    <f:facet name="nodeStamp">
        <af:column id="c1">
            <af:outputText value="#{node}" id="ot2"/>
        </af:column>
    </f:facet>
    <f:facet name="pathStamp">
        <af:outputText value="#{node}" id="ot3"/>
    </f:facet>
</af:treeTable>

This code, when put inside a simple page with an af:panelColletion, will produce this output:

As you see, there is only one column. You would not even know that you look at an af:treeTable. OK, the af:treeTable binding used is very simple:

For the first level and for the second level

In the remainder of this post, I show how to build a better-looking version with columns for the different data shown.

As usual, you can download the sample code from GitHub. See the link at the end of this post.

Small changes

To see the whole information in the one tree table column, we change the size of the column to 200px

<af:treeTable value="#{bindings.DepartmentsView1.treeModel}" var="node"
              selectionListener="#{bindings.DepartmentsView1.treeModel.makeCurrent}"
              rowSelection="single" id="tt1">
    <f:facet name="nodeStamp">
        <af:column id="c1" width=”200”>
            <af:outputText value="#{node}" id="ot2"/>
        </af:column>
    </f:facet>
    <f:facet name="pathStamp">
        <af:outputText value="#{node}" id="ot3"/>
    </f:facet>
</af:treeTable>

to get this output which shows all data, but still all in one column:

nodeStamp and pathStamp

When you look at the generated af:treeTable tag you’ll notice two facets:

nodeStamp and pathStamp

 

The nodeStamp facet is used to render the tree table and lets you drill down the data defined in the binding of the tree table.

To render the tree table a special EL, normally ‘#{node}’, is used to stamp out the data of each level. Which data is stamped is defined in the tree binding. We defined to show the DepartmentName name for the first level and EmployeeId, LastName and FirstName for the second level. This is why we get the output in the image above.

In summary: the nodeStamp renders the first column of the tree table.

The pathStamp is used for navigation inside the af:treeTable like when you select a node and make it the top node of the tree or tree table. For more info on this check the documentation.

Building columns:

An af:treeTable, like a table, can and should have columns. As you see in the image above, the af:treeTable looks like a normal tree when you don’t define columns yourself.

Columns are defined outside the ‘nodeStamp’ facet (and pathStamp facet) of an af:treeTable. The tag doc tells us:

Columns

Like the Table, the TreeTable’s children must be Column components (see Table Columns). Like the Tree, the TreeTable has a “nodeStamp” facet which renders the “Object Name” Column. The “Object Name” Column contains the primary identifier of an element in the hierarchy. For example, in an organization chart of employees, the “Object Name” Column might be the employee name.

 

Sample: to show columns for Lastname and FirstName of an Employee we add af:column tags like

<af:treeTable value="#{bindings.DepartmentsView1.treeModel}" var="node"
              selectionListener="#{bindings.DepartmentsView1.treeModel.makeCurrent}"
              rowSelection="single" id="tt1">
    <f:facet name="nodeStamp">
        <af:column id="c1" width=”200”>
            <af:outputText value="#{node}" id="ot2"/>
        </af:column>
    </f:facet>
    <f:facet name="pathStamp">
        <af:outputText value="#{node}" id="ot3"/>
    </f:facet>
    <af:column id="c2" width="200">
        <af:outputText value="#{node.LastName}" id="ot4"/>
    </af:column>
    <af:column id="c3">
        <af:outputText value="#{node.FirstName}" id="ot3"/>
    </af:column>
</af:treeTable>

outside the nodeStamp facet. This will get us this output

Now we have a problem. The second level nodeStamp prints out all attributes of hte node. This is exactly what the EL ‘#{node}’ does. The first level doesn’t have this problem as we only defined one attribute ‘DepartmentName’ for this node.

We don’t like to see the sting in the 2nd level. There exist two solutions to solve this problem.

  1. We use the EL ‘#{node.DepartmentName}’ instead of ‘#{node}’. As the attribute DepartmentName doesn’t exist in level 2, the EL evaluates to nothing (or empty string). However, keep in mind that this only works if the attribute only exists in level one.

  1. We define an EL for the node depending on their level. This solution will work in all cases. To implement this we use an af:switcher component which we use to find out which level we are currently stamping out. This allows us to use attributes defined for the level and build some output for the nodeStamp. Details for this solution follows below.

How to find out which node level currently is stamped out?

One easy way is to look at the view objected used for the level. If you are using some other source you can add an attribute (static) for each level which can then be used in the EL for the af:switcher.

To find out the name of The view object used we can look at the source of the tree binding in the pagedef

  <bindings>
    <tree IterBinding="DepartmentsView1Iterator" id="DepartmentsView1">
      <nodeDefinition DefName="de.hahn.blog.treetable.model.views.DepartmentsView" Name="DepartmentsView10">
        <AttrNames>
          <Item Value="DepartmentName"/>
        </AttrNames>
        <Accessors>
          <Item Value="EmployeesView"/>
        </Accessors>
      </nodeDefinition>
      <nodeDefinition DefName="de.hahn.blog.treetable.model.views.EmployeesView" Name="DepartmentsView11">
        <AttrNames>
          <Item Value="EmployeeId"/>
          <Item Value="LastName"/>
          <Item Value="FirstName"/>
        </AttrNames>
      </nodeDefinition>
    </tree>
  </bindings>

The name we are looking for is the DefName of the nodeDefinition. But how do we access this information in an EL?

Frank Nimphius blogged about this here https://blogs.oracle.com/jdevotnharvest/how-to-determine-the-adf-tree-node-type-using-el. We use the EL

#{node.hierTypeBinding.viewDefName}

which returns the nodes DefName from the binding.

With this info, we can build the af:treeTable

<af:treeTable value="#{bindings.DepartmentsView1.treeModel}" var="node"
              selectionListener="#{bindings.DepartmentsView1.treeModel.makeCurrent}"
              rowSelection="single" id="tt1">
    <f:facet name="nodeStamp">
        <af:column id="c1" width="200">
            <af:switcher facetName="#{node.hierTypeBinding.viewDefName}"
                         defaultFacet="default" id="sw1">
                <f:facet name="de.hahn.blog.treetable.model.views.DepartmentsView">
                    <af:outputText value="#{node}" id="ot2"/>
                </f:facet>
                <f:facet name="de.hahn.blog.treetable.model.views.EmployeesView">
                    <af:outputText value="ID: #{node.EmployeeId}" id="ot11"/>
                </f:facet>
                <f:facet name="default">
                    <!-- use this facet if the other facets don't match! -->
                    <af:outputText value="#{node}+++++#{node.hierTypeBinding.viewDefName}"
                                   id="otd11"/>
                </f:facet>
            </af:switcher>
        </af:column>
    </f:facet>
    <af:column id="c2" width="200">
        <af:outputText value="#{node.LastName}" id="ot4"/>
    </af:column>
    <af:column id="c3">
        <af:outputText value="#{node.FirstName}" id="ot3"/>
    </af:column>
</af:treeTable>

to get this output

Using the same technique in the columns allows showing even more information.

How about showing the manager of each department next to the department in the column where the employees are shown?

Easy, after changing the DeparmentView to return the manager info together with the department

and adding attributes for MgrEmployeeId, MgrLastName and MgrFirstName we can implement this using the following code

<af:treeTable value="#{bindings.DepartmentsView1.treeModel}" var="node"
              selectionListener="#{bindings.DepartmentsView1.treeModel.makeCurrent}"
              rowSelection="single" id="tt1">
    <f:facet name="nodeStamp">
        <af:column id="c1" width="200">
            <af:switcher facetName="#{node.hierTypeBinding.viewDefName}"
                         defaultFacet="default" id="sw1">
                <f:facet name="de.hahn.blog.treetable.model.views.DepartmentsView">
                    <af:outputText value="#{node.DepartmentName}" id="ot2"/>
                </f:facet>
                <f:facet name="de.hahn.blog.treetable.model.views.EmployeesView">
                    <af:outputText value="ID: #{node.EmployeeId}" id="ot11"/>
                </f:facet>
                <f:facet name="default">
                    <!-- use this facet if the other facets don't match! -->
                    <af:outputText value="#{node}+++++#{node.hierTypeBinding.viewDefName}"
                                   id="otd11"/>
                </f:facet>
            </af:switcher>
        </af:column>
    </f:facet>
    <af:column id="c2" width="200">
        <af:switcher facetName="#{node.hierTypeBinding.viewDefName}" defaultFacet="default"
                     id="sw2">
            <f:facet name="de.hahn.blog.treetable.model.views.DepartmentsView">
                <af:outputText value="#{not empty node.MgrLastName ? 'Manager: ' : ''}"
                               id="ot5" inlineStyle="font-weight:bold;"/>
                <af:outputText value="#{not empty node.MgrLastName ? node.MgrLastName : ''}"
                               id="ot6"/>
                <af:outputText value="#{not empty node.MgrLastName ? ', ' : ''}" id="ot4"/>
                <af:outputText value="#{not empty node.MgrLastName ? node.MgrFirstName : ''}"
                               id="ot7"/>
            </f:facet>
            <f:facet name="de.hahn.blog.treetable.model.views.EmployeesView">
                <af:outputText value="#{node.LastName}" id="ot211"/>
            </f:facet>
            <f:facet name="default">
                <!-- use this facet if the other facets don't match! -->
                <af:outputText value="#{node}+++++#{node.hierTypeBinding.viewDefName}"
                               id="otd211"/>
            </f:facet>
        </af:switcher>
    </af:column>
    <af:column id="c3">
        <af:outputText value="#{node.FirstName}" id="ot3"/>
    </af:column>
</af:treeTable>

Will produce this tree table:

You can add more, like icons in each column or …

You can download the sample application from GitHub: BlogTreeTable. The sample was built using JDev 12.2.1.3 but the same technique should work in other JDev versions too (11g or newer).

JDev 12.2.1.3: Creating a shared skin jar (Part 2)

In part 1 or the series we created a simple skin, built an ADF-Library from it and tried to reuse it by deploying it to a WebLogic Server. This approach failed. In this part, we try another option to share a jar with

Sharing the skin with other applications

To share the skin with other application we can

  1. Create an ADF Library
    1. Add this library to the other application
    2. Add this library as a shared library to a WebLogic Server
  2. Create a normal jar
    1. Add this library to the other application
    2. Add this library as a shared library to a WebLogic Server

For this blog the way we want to use if 2b. This allows to create the skin once, deploy it to a server and use it in every other application. In the next paragraph, we try out option 1a to show the problems when reading resources from a jar file.

Using a shared skin

Option 2b

Here we create a jar file containing the skin and additional resources like images and deploy it directly to a WebLogic Server as a shared library. The advantage is, that other applications can use the skin and other resources directly and that the jar can be versioned to allow different versions of the same jar on the server.

Option 1a which we discussed in the previous chapter doesn’t work for images. However, the documentation ‘Deploying a Custom Skin File in a JAR File’ and Frank Nimphius pointed it out in e.g. 86. Reading boilerplate images and icons from a JAR or How-to share skin definition files across applications how the jar file must be structured to allow the resource servlet to read the resources. The essential sentence is

‘All image resources and CSS files must also be under the META-INF directory.’

In his article, Frank suggested using the command line jar tool to create the jar. I show how to use JDev to create the jar with the needed structure and how to deploy it to a server as a shared library.

A sample application is used to use the skin and to show an image load from the jar.

The building plan for a skin in a shared Library which can be deployed to a WebLogic server is given in the article as:

To implement the shared library approach, developers need to change their existing skin definition so it can be deployed in a JAR file. The steps for this include

– Creating a META-INF directory – Creating a trinidad-skins.xml file that defines the skins deployed with the JAR file

– Creating an META-INF/adf sub directory for images and icons served from the JAR file

– Changing the image reference in the CSS to include the “adf” directory, which makes sure images and icons are handled by the ADF Faces resource loader, which can read resources from JAR files

– JAR the META-INF directory to create the library file

Looking at the current project for the skin we see a different layout

In the article Frank instructed to create the needed folders yourself and copying or moving the files to the new structure, then to use the command line to build a jar from the structure.

I’ll show how this can be done with a special deployment descriptor from within the project. The image below shows the needed layout of the final jar file.

To transform the folder structure present in JDev to the needed structure of the final jar, we create a new deployment descriptor in JDev

In image 4 we see the first part of the solution: here we set the path inside the jar to ‘MEAT-INF’. This will guarantee the structure we need. Then we add another contributor to the list (public_html) to get everything we need into this folder. Then we use the ‘Filters’ node to select all content we need skin part

Next part is to create another path in the jar for the metadata of the skin

We add another file group for the resources

Now we can deploy the jar using the new deployment descriptor

And the jar file is created in the deploy folder. It holds all files in the right folders

Finally, we can deploy this jar to the WebLogicServer. In this case, I use the integrated WLS, but it can be any stand-alone WLS too.

The error message you see on the 7th image can be ignored. It only tells you that the library can’t be deployed as an application but only as a shared library. This is exactly what we want to do 🙂

Now the jar file is deployed on the WLS as a shared library and can be used for every application on this server.

We use the existing application from part one to consume the jar skin from the shared library and show the images deployed with the jar.

Before we go any further, we have to remove the ADF Library we added to show the problem from the project. For this open the project properties and select the ‘Library/Classpath’ node and remove the ‘ADFLibrary’ entry

The page should now look like no skin is used at all.

As we already added a skin (with the ADF Library) we don’t have to do this again. However, we have to add a library reference to configure the application to use the shared library deployed on the server. For this, we open the application descriptors and edit the ‘weblogic-application.xml’ file by double clicking the entry in the application resources section

In the ‘Shared Library Reference’ section, we add a reference to the now deployed shared jar ‘blogsharedskin’

Saving everything we don’t see any change to the page design, as the library isn’t part of the application yet. Starting the application we get

Just what we liked to see. The images are visible, checking the page with Chrome’s Dev Tools shows that the images are correctly loaded

This proves that the shared library with the skin and the images are working correctly.

To make the skin visible in JDev during development, we can add the jar we developed to the server a library. We create a library

and make sure the ‘Deploy by default’ is NOT set. Adding the library to the project

will make the skin visible in design mode

The unset checkmark prevents the jar from being packed into the WAR or EAR file. It’s just used in the IDE. That you can’t see the images is normal as there is no full server to serve the images to the design view.

Summary

In this mini-series, I showed the problem when creating a skin as ADF Library and trying to share it on a Weblogic Server. Then I showed how to create a deployment descriptor for the skin and other resources and how to deploy the resulting jar to a WebLogic Server.

The sample application can be downloaded from BlogSharedSkin. The sample was created by using JDev 12.2.1.3 but the same technique can be used in any 12.2.1.x JDev version. There is no database connection needed.

JDev 12.2.1.3: Creating a shared skin jar (Part 1)

In earlier versions of JDev, skins have been created either by pure code or by using the free Skin Editor. However, since JDev 12.2.1.x the skin editor has been integrated into JDeveloper itself.

A couple of questions in the ODC JDeveloper space are about how to create a skin with JDev which can be deployed as a shared library to a WebLogic Server. I gave this a try and it turned out, that you can build an ADF library jar from a skin project but you can’t use images to this jar which you might want to use in the application.

In this blog, I’ll show how to create a skin with resources like images and how to build a jar file from the skin together with the images and deploy it aa s shared jar to a WeblogicServer.

Building a skin project

The first part is to build a small skin project. The project we use to create a minimal skin, just to show that the skin is changing something. Then we add some images to the skin which we want to use in the application which uses the skin. Such images can e.g. used on an af:button component.

We start by creating a new application as an ‘ADF Fusion Web Application’

As we don’t need the created model project we delete it completely

If you get another dialog, telling you that you can’t undo the action, answer ‘Yes’ to delete the project. Now you should see a workspace with just the one project:

Know that we have a project we add a skin and e.g. add some skin selectors to change to the color of the button text. For this, we right click the ‘Web Content’ folder in the project and select ‘New from Garaly’ and then select ‘ADF Skin’ from the ‘JSF/Facelets’ node and fill in the basic information:

This will create the needed css file and the descriptors which define our skin (trinidad-config.xml and trinidad-skins.xml).

We open the sharedskin.css file if it’s not open already and switch to source mode. Here we add two simple skin selectors

which are changing the color of the text of a button and a link. You can add more sophisticated selectors but for this blog, it’s enough to show the working skin. To make it more interesting, and because that’s the real reason for this blog, we add some images to the skin which we like to use in the application using the skin. We add the images into a new folder like shown below

The reason for this structure is, that to read the images from the jar in the consuming application, we need a special resource loader. In case of ADF it’s the resource servlet which listens to the URL pattern ‘/adf/’’. This servlet is installed automatically for ADF Web Applications and is configured in the web.xml file

The final task for the skin project is to create a jar file which we can use in other applications. The easiest way to get such a jar is to create an ADF Library deployment descriptor. Open the project properties of the skin project and select the ‘Deployment’ node

And click the ‘New Profile’ icon, select to create an ADF Library Jar

and click ‘OK’. The remaining dialogs you can just click ‘OK’ or ‘Finish’.

To create the library we have to execute the descriptor by right-clicking on the project and selecting ‘Deploy’ and choosing the ‘sharedskinadflib’

This will create the jar in the ‘deploy’ folder of the project.

Sharing the skin with other applications

To share the skin with other application we can

  1. Create an ADF Library
    1. Add this library to the other application
    2. Add this library as a shared library to a WebLogic Server
  2. Create a normal jar
    1. Add this library to the other application
    2. Add this library as a shared library to a WebLogic Server

For this blog, we want to use option 2b. This allows to create the skin once, deploy it to a server and use it in every other application. In the next paragraph, we try out option 1a to show the problems when reading resources from a jar file.

Using a shared skin

Option 1a

We start with option 1a, just to show the problem when we try to read a resource from a jar. We build another ADF Fusion Web application and add the skin as ADF library from a ‘File System Connection’ which we create and let it point to the ‘deploy’ folder

Right-click on the ‘sharedskinadflib’ and add it to the new sample project. This will make the skin available to the application. To use the skin we have to add a skin to the application like we did to create the skin project. The difference is that we now choose the shared skin as the base skin

Creating a new page and adding a button and/or a link to the page we see the new style introduced by the ‘sharedskin’

So, the shared skin is working. Well, yes, but what about the images we added to the ‘sharedskin’?

Let’s try to add one to the button. In the property editor, we select the icon property of the button and click ‘Edit’ to get

However, we don’t see any image in the whole project. As we know where we put the images (or we can look into the sharedskinadflib) we can just add the path to the image like ‘skins/sharedskin/adf/images/home.png’ and we see the image

Running the application we get the page with the button but don’t see the image

Using DeveloperTools we see that the resource couldn’t be found. Inspecting the button element we see

The path to the image is not found 😦

If we change the address of the image to ‘/adf/images/home.png’ to use the resource servlet we still get an error

The reason is that the resource servlet expects the resources in a different path inside the jar. Every resource which should be read from a jar should be in a folder named ‘META-INF’.

The ADF library did not put the images into the META-INF folder

The problem is that we can’t change the layout of the ADF Library. When you create an ADF Library there is no option to make any changes to the content of the jar.

The conclusion is that using a skin in an ADF Library is problematic if there are other resources which you need to share.

To be continued…

In the final part 2 of the series, we see how the skin can be shared with other applications.

JDev 12c: Badge Button reloaded

In my article JDev: Badge Button I showed how to build a special button with a notification ‘badge’:

The declarative component of this sample was build using JDev 11g (11.1.1.9.0 to be exact).

I received a couple of question on how to work with this declarative component in JDev 12c projects. In general, you can use the same source and build the declarative component in JDev 12c. However, as JDev 12c is using a different document type, Facelets instead of JSP XML, you can use the badge button only on JSPX type pages.

So, in this blog, I show how to create a declarative component which is usable in Facelets type pages. I don’t change the behavior of the badge button but reuse the code. This blog is more about how to create a declarative component in 12c and show the differences to 11g.

JSPX vs. Facelets

With the introduction of JSF 2.0 (JavaServer Faces 2.0 Overview and Adoption Roadmap in Oracle ADF Faces and Oracle JDeveloper 11g) a new document type Facelets was introduced. The difference and the motivation behind this is outlined in the document.

We are only interested in the fact that you can’t mix components designed for JSPX XML pages or fragments with Facelets type pages or fragments. This means that you can’t add the badge button created for 11g to a jsf page of jsff fragment of type ‘Facelet’.

Building a Declarative Component for 12c

We start from the old application workspace I created for the 11g implementation. Opening this workspace will migrate it to the 12c. At the end of the blog, you’ll find a link to download the final workspace for 12c.

After the migration we add a new project ‘BBB12cDeclarativeComponent’ of type ‘ADF ViewController Project’ to the workspace:

After creating a new project for the 12c badge button, we create a new ‘Declarative Component’ in the ‘Web Content’ folder

In the wizard, we now select ‘Facelets’ as the document type. Selecting ‘Facelets’ will create the 12c kind of declarative component.

Once we finished the wizard, we get the skeleton declarative component in the ‘BadgeButton12c.jsf’ file. If you got a file name ‘BadgeButton.jspx’ you did not set the document type to ‘Facelets’.

Now we can copy the code from the original sample written for 11g and copy it after the componentDef tag. Once you copied the code from the original sample you have to change the EL used to address the action and the actionListener to match the componentVar property in the componentDef tag. To make this distinguishable from the 11g sample, I changed the componentVar to ‘compButton’. The other change is to use an af:button tag instead of the af:commandButton tag. While the af:commandButton tag can still be used, 12c application should use the af:button tag.

 

The final code looks like

Adding the declarative component to the faces palette

You already know, that to use the declarative component in a project, you first have to add it to the component palette. The difference to the 11g sample is that we have to choose a different node in the project definition to add the library.

First, we need to deploy the declarative component project to an ADF Library. For this, all we need to do is to execute the deployment profile created with the project

Next, we add a ‘File System’ resource which points to the folder the jar is created in

And the jar should show up

To make it usable in the view controller project, we have to add the jar to the project

Now, when we look into the view controller projects properties, we find the new declarative component in the ‘Facelets Tags Libraries’ node. In JDev 11g the tab libraries can be found in the node ‘JSP Tag Libraries’. Again, the difference is where the tags or declarative component are usable. You use JSP tags in JSP XML files and you use Facelets tags in JSF files.

Next step is to create a new JSF Page in the adfc-config.xml, the unbounded task flow.

Again, we make sure to select ‘Facelets’ as document type as we otherwise will not be able to use the declarative component created for ‘Facelets’.

The layout of the page is similar to the one for 11g. 12c uses a panelGridLayout instead of the panelStretchLayout, but that’s all.

As we are now using a JSF page and added the 12c component library and find the BadgeButton in the component palette

and use this on the page. The final layout looks like

Or when running the JSF page

Clicking the button we get the log messages

Sample Application

You can download the sample application from GitHub BlogBadgeButton12.2.1.2