One of the requirements at my current project is to have one ADF table display data from different database tables. That is, depending on criteria entered by the user, the query behind the view object needs to change. All in all 12 different database tables are involved in this story. This requirement is based on functionally in the original (oracle forms) application. This forms application used the set_block_property built-in:
I was able to reproduce this behavior in an ADF application. In this post I explain how I did this.
Database and ADF Business Components.
Luckily these tables all have the same attributes so it is relatively easy to achieve this. I created two database views. One based on the employees table, and a second one based on the locations table. Mark that I defined identical column aliases for both views.
Next I created an ADF Business Components viewObject based on one of the database views. I called this viewObject 'dataprovider'.
ADF Faces Page.
To display the data on a page I just created a simple page and dropped the collection from the datacontrol pallet onto the page as an ADF Table component. When running the page, you see data from the emp_abstract_vw as expected.
Preparing the Query Change Method.
In order to change the query I have to create a method on the application module. This method gets a handle to the viewObject, sets some properties, changes the query and executes it. Ok, not that fast. In the codefragment below you see one line where I use setFullSqlMode. Lets explain what FULLSQL_MODE_AUGMENTATION does.
First I apply the new programmatic query by calling setQuery() and execute the query. If I need to call setWhereClause or if a user changes criteria the query, the ADF Business Components framework augments the whereClause on the programmatic query. If you don't use FULLSQL_MODE_AUGMENTATION any changes by setWhereClause or change of query criteria are applied to the original query (that is the query that was defined design time).
Next step is to publish this method so I can use it on my page. I drop the method from the datacontrol, resulting in a methodAction in my bindingcontainer.
Final step is the implementation of a selectOneChoice with a value change listener to change the basetable for the query. The selected value corresponds to the name of one of the database views, and will be directly applied to the viewObjects' query.
The valueChangeListener executes the methodBinding, thus changing the query.
Now when you start the application you will see the table displaying all employees.
This is the default query behind the viewobject.
By changing the value of the listbox, you will also change the viewobjects' query, resulting in locations data being displayed in the table.
This post was originally posted at the AMIS Technology Blog
set_block_property('<blockName>, query_data_source_name, <datasource>);
I was able to reproduce this behavior in an ADF application. In this post I explain how I did this.
Database and ADF Business Components.
Luckily these tables all have the same attributes so it is relatively easy to achieve this. I created two database views. One based on the employees table, and a second one based on the locations table. Mark that I defined identical column aliases for both views.
create view EMP_ABSTRACT_VW as
select
EMPLOYEE_ID IDENTIFIER,
FIRST_NAME DESCRIPTION
from employees
create view LOC_ABSTRACT_VW as
select
location_id IDENTIFIER,
city DESCRIPTION
from LOCATIONS
Next I created an ADF Business Components viewObject based on one of the database views. I called this viewObject 'dataprovider'.
select
IDENTIFIER objId
,DESCRIPTION objDesc
from emp_abstract_vw
ADF Faces Page.
To display the data on a page I just created a simple page and dropped the collection from the datacontrol pallet onto the page as an ADF Table component. When running the page, you see data from the emp_abstract_vw as expected.
Preparing the Query Change Method.
In order to change the query I have to create a method on the application module. This method gets a handle to the viewObject, sets some properties, changes the query and executes it. Ok, not that fast. In the codefragment below you see one line where I use setFullSqlMode. Lets explain what FULLSQL_MODE_AUGMENTATION does.
First I apply the new programmatic query by calling setQuery() and execute the query. If I need to call setWhereClause or if a user changes criteria the query, the ADF Business Components framework augments the whereClause on the programmatic query. If you don't use FULLSQL_MODE_AUGMENTATION any changes by setWhereClause or change of query criteria are applied to the original query (that is the query that was defined design time).
1: static String baseQuery = "select IDENTIFIER objId, DESCRIPTION objDesc from ";
2: public void changeBaseTable(String baseTable){
3: String query = baseQuery + baseTable;
4: ViewObjectImpl voi = getdataProvider();
5: voi.setFullSqlMode(voi.FULLSQL_MODE_AUGMENTATION);
6: voi.setQuery(query);
7: voi.executeQuery();
8: }
Next step is to publish this method so I can use it on my page. I drop the method from the datacontrol, resulting in a methodAction in my bindingcontainer.
1: <methodAction id="changeBaseTable" RequiresUpdateModel="true"
2: Action="invokeMethod" MethodName="changeBaseTable"
3: IsViewObjectMethod="false" DataControl="AppModuleDataControl"
4: InstanceName="AppModuleDataControl.dataProvider">
5: <NamedData NDName="baseTable" NDType="java.lang.String"/>
6: </methodAction>
Final step is the implementation of a selectOneChoice with a value change listener to change the basetable for the query. The selected value corresponds to the name of one of the database views, and will be directly applied to the viewObjects' query.
1: <af:selectOneChoice label="Basetable...>>> " id="soc1"
2: value="#{pageFlowScope.SwitchIterator.baseTable}"
3: autoSubmit="true"
4: valueChangeListener="#{pageFlowScope.SwitchIterator.switchBaseTable}">
5: <af:selectItem label="Employees" value="EMP_ABSTRACT_VW"
6: id="si1"/>
7: <af:selectItem label="Locations" value="LOC_ABSTRACT_VW"
8: id="si2"/>
9: </af:selectOneChoice>
The valueChangeListener executes the methodBinding, thus changing the query.
public void switchBaseTable(ValueChangeEvent valueChangeEvent) {
setSource(valueChangeEvent.getNewValue().toString());
}
public void setSource(String baseTable) {
// Add event code here...
DCBindingContainer bc = (DCBindingContainer)BindingContext.getCurrent().getCurrentBindingsEntry();
OperationBinding oper = bc.getOperationBinding("changeBaseTable");
oper.getParamsMap().put("baseTable", baseTable );
oper.execute();
}
Now when you start the application you will see the table displaying all employees.
This is the default query behind the viewobject.
By changing the value of the listbox, you will also change the viewobjects' query, resulting in locations data being displayed in the table.
This post was originally posted at the AMIS Technology Blog
Comments