ADF Query Component Usage with ADF Panel Stretch Layout

There is a very nice layout component in ADF 11g - af:panelStretchLayout (ADF Panel Stretch Layout). This component comes with 5 facets - Bottom, Center, End, Start and Top. It allows to split your page layout in more easy way - you can put menu component into Top facet, functional logic into Center facet.

Everything seems okej and clear, however there is hidden issue when you need to have menu elements in Top facet dependent on ADF Query from Center facet. For example, menu item can be enabled/disabled based on ADF Query results:


It will not work for you by default, during initial page rendering. Because when menu items in Top facet are rendered, ADF Query from Center is not initialized yet - iterator will bring all rows. This means, even if ADF Query is configured not to bring any results by default, in Top facet all rows still will be visible. ADF Panel Stretch Layout facets are rendered in following order - Top, Start, Center, Bottom and End.

Steve Muench proposed to initialize ADF Query in Top facet by referencing Query Model. And it works - menu is rendered correctly. You can download my sample application - PanelStretchLayoutADFQuery.zip where this solution/workaround is implemented.

I'm referencing Query Model for ADF Query from hidden (visible = false) af:outputText component I have created in Top facet right before Menu items:


This allows to initialize ADF Query before actually rendering complete af:query component.

At runtime, when your page will be rendered, you will have correct behavior - menu item disabled when there are no results by default:

Menu item becomes enabled when results table is populated:


Popup opened from menu item to edit data for selected row:


Data in popup is updated when selecting other row:


Just quick note, by default data in Popup will not be changed, you need to set ContentDelivery=lazyUncached property for af:popup component in order to have correct behavior:


Spanish Summary:

ADF Panel Stretch Layout es un componente del tipo panel que podemos usarlo para organizar la página. Este componente esta compuesto de 5 facets(regiones) en donde podemos colocar otros componentes visuales.

Una de las prácticas más comunes con los panelStretchLayout es incluir en la región superior (TOP) un menú que obtienen su información en base a un componente ADF Query ubicado en la región CENTER. Bien, este tipo de disposición tiene un inconveniente por el orden en el cual se construyen los componentes. Por ello Andrejus ofrece en este post uno tips que nos ayudan a solucionar estos inconvenientes.

Spanish Summaries from JDeveloperLA

My colleague from Oracle ACE Director program - Plinio Arbizu, kindly offered to provide summaries in Spanish language for my blog posts. Plinio lives in Lima, Peru and runs JDeveloper focused site in Spanish language - JDeveloperLA. According my blog statistics I can see lots of visitors from Spanish speaking countries, I believe our initiative will be useful.

My last 7 posts are already with summary in Spanish. For new posts, I will add on regular basis.

Spanish Summary :

A partir de ahora, cada entrada en el blog de andrejus tendrá un breve resumen en español que explicará los objetivos de cada experiencia desarrollada con la tecnología ORACLE.

Estos comentarios se colocarán al finalizar cada artículo y estarán a cargo de Plinio Arbizu (Oracle ACE Director - Perú), quien además publica información sobre Jdeveloper por medio del portal www.JdeveloperLa.com.

Panel Collection and Hidden Columns

In 11g, I like af:panelCollection (Panel Collection) component. I like it, because I can surround af:table component with Panel Collection and get additional functionality for free. For example, often there is a requirement not to show specific columns by default, however allow user to select them later. In 10g, there was no standard way to do this, in 11g it comes with Panel Collection functionality.

In this example, af:table is surrounded by af:panelCollection:


Let's say we will hide some column, one of them will be Email. Column is hided by setting Visible property to false:


On runtime, af:panelCollection will be rendered with View menu item and other features. It contains toolbar facet, I have dragged and dropped my buttons there. From View menu item I can select Columns section, where all table columns are listed. Those columns, hidden by default, are listed as well:


When user selects one from the list, for example Email, our table is refreshed and previously hidden column becomes visible:


Download sample application - PanelCollection.zip.

Spanish Summary:

Titulo: Esconder columnas en un Panel Collection.

Resumen: En este ejemplo observaremos como aprovechar el Panel Collection para definir columnas ocultas las cuales luego pueden ser mostradas dinámicamente por los usuarios.

Practical ADF Security Deployment on WebLogic Server

When it will come time for you to deploy your application, you may face problems with ADF Security Policies migration to standalone WebLogic server. If this step is described in Steve Muench article - Simplified ADF 11g Application Credential and Policy Migration to Standalone WebLogic Servers, second thing is not described clearly in documentation - how to make work authorization when application is deployed on standalone WebLogic server. I got useful hints after watching Frank Nimphius ADF Code Corner Internet TV - ADF Security Authorization, recommend to check as well.

In this post I will describe step-by-step how to deploy your Web application with ADF Security enabled on standalone WebLogic server. You can download my sample application, I was deploying and testing - ADFSecurityWL.zip. ADF BC Application Module is configured to use JDBC DataSource - java:comp/env/jdbc/HrDS, dont forget to define jdbc/HrDS JNDI on your server, before running application.

So, what is not clearly described in documentation is that standalone WebLogic server can see only so called Enterprise roles defined with following class:

• oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl defined in jazn-data.xml

• weblogic.security.principal.WLSGroupImpl converted to WebLogic class after Policies migration
  

During development, Enterprise roles can be defined in jazn.com identity store:


You need to know, that Enterprise roles are not used to define policies. For ADF Policies are used Application class roles. During development, those roles are defined under Application Policy Store.


And its very important - if you want your Application class role to be functional on standalone WebLogic server with Authentication Provider, you need to map Application role to appropriate Enterprise role. This mapping can be done in jazn-data.xml file. In this example, Application class role - managers is mapped to Enterprise class role - managersApplication:


Enterprise role later will be defined in standalone WebLogic server Authentication Provider. This will allow to define new application users, not only those used during development.

Here is an example of Application class role usage to define ADF Security Policy related to a Web page access:


I'm using second Application role - managers, in order to disable/enable specific button in my application:


You should now, there is no need in this case to map your Enterprise class roles to WebLogic roles in weblogic.xml. Its enough to have mapping generated by ADF Security wizard - valid-users to users:


ADF Security role - valid-users, charachterize defined Enterprise class roles.

When roles are defined, its time to deploy your application. I have configured Application Module to use JDBC DataSource - java:comp/env/jdbc/HrDS:


I should mention very funny bug here. Its impossible to define JDBC DataSource with different name comparing to your defined name for database connection. Let's say if we have defined DB connection with a name Hr, when you will choose JDBC DataSource option, JDeveloper automatically will supply following JDBC DataSource - java:comp/env/jdbc/HrDS. JDeveloper takes DB connection name Hr and adds DS. If you will change this JDBC DataSource name to anything else, for example - java:comp/env/jdbc/HrDSMY and will define same JDBC DataSource on standalone WebLogic - it will not work. Why??? Simply, because during EAR generation process, JDeveloper adds additional JDBC DataSource configuration to web.xml file. And no difference what name you have specified, it will always put into web.xml JNDI name constructed by default from your DB connection name. Here is this entry in web.xml, it is added only during EAR generation process and is not available in application under development:


I wish, Oracle will fix this bug.

Ok, when application is deployed, you can migrate your ADF Security Policies as it is described in Steve Muench article. After migration, in your system-jazn-data.xml on standalone WebLogic domain, you will have similar entries:


You can see two Enterprise class roles, visible to WebLogic, defined:

1. employeesApplication
2. managersApplication
   

Two Application class roles are dependent:

1. employees
2. managers
   

After you will restart standalone WebLogic server, you can define your users and their roles with default Authenticaton Provider. For my application, I have defined two users. First is - sking:


Second is - anuhold:


First user have both two roles, second is assigned with only one role.

On runtime, if application will be accessed by anuhold:


User will be authorized to open a page, however - Salary Graph button will be disable, since user is not assigned with managersApplication role:


When opening application with sking user:


Authorization is passed for both - page and Salary Graph button:


Here is a graph with Salary values:


Spanish Summary:

Titulo: Como desplegar aplicaciones ADF (que usan la característica de seguridad ADF Security) en servidores BEA WebLogic.

Resumen: Andrejus en este capitulo, no muestra de manera practica como crear un repositorio de usuarios y roles en BEA WebLogic y aplicarlos a las politicas de seguridad de nuestras aplicaciones ADF.