Showing posts with label Cascading. Show all posts
Showing posts with label Cascading. Show all posts

Monday, March 8, 2010

Cascading LOV in detail view dependent on master view attribute

In some cases we have LOVs in detail view objects that are dependent on an attribute on a master view object.

For example in Departments Employees Master detail, you want to have a list of values for Employees managers to be the department Manager or employees that have the department manager. The LOV query would be :
select *
from employees
where manager_id = :inManager
or employee_id = :inManager

In the view accessor for the LOV you can set the bind variable of the LOV to get value from the master view object ‘DepartmentsView.ManagerId’ or in the employees view object you can add Departments entity and add attribute ManagerId from Departments Entity.

Yet when you change Manager of the Department in both cases the LOV does not know that the bindVariable value has changed and it is still executed with the old value of Department value.

This is happening because the LOV is notified to take new bind value when the setter of the dependent attribute is invoked.

In order to do that I created an updatable transient attribute LOVManagerId that on the getter when it has no internal value it gets the value from Departments entity reference attribute.

public Number getLOVManagerId() {
if (getAttributeInternal(LOVMANAGERID)==null)
return this.getDepartmentManagerId();
return (Number) getAttributeInternal(LOVMANAGERID);
}



Now on the getter of reference entity attribute I check if entity attribute has changed in order to set also the LOVManagerId.

public Number getDepartmentManagerId() {
Number empdepManager = (Number) getAttributeInternal(DEPARTMENTMANAGERID);
if (this.getDepartments().isAttributeChanged("ManagerId"))
this.setLOVManagerId(empdepManager);
return empdepManager;
}

Partial triggers form Department.ManagerId field to Employees table will finish the job.



Test Case :
http://adfbugs.googlecode.com/files/MasterDependentLOV.zip

Thursday, February 11, 2010

New Cascading LOV with required View Criterion Not a Bug

On july 2009 in the patch of jdeveloper (11.1.1.1.0) a new feature was introduced in view criteria. When a criterion is required then an error message is shown to user. Of course not without side-effects (http://adfbugs.blogspot.com/2009/07/query-component-required-criterion-bug.html)
On the latest patch of jdeveloper (11.1.1.2.0) a new feature and bugs was introduced in view criteria (http://adfbugs.blogspot.com/2010/01/new-bind-variable-and-view-criteria-bug.html)
The above bugs also effected the functionality of LOVs especially of those that use view criteria, either for selective required (http://adfbugs.blogspot.com/2010/01/selectively-required-criteria-in-lov.html) or for cascading LOVs.

In the current test case I have Employees and I want the List of value of Managers to depend on the department of the employee. I expect when the user has not selected a department the List of values of managers to be empty



Yet when I run application, just when I set department to null I get the following error.

ADF: Adding the following JSF error message: Attribute DepartmentId is required.
oracle.jbo.AttrValException: JBO-27035: Attribute DepartmentId is required.
at oracle.jbo.rules.JboVCItemRequiredValidator.validateItem(JboVCItemRequiredValidator.java:91)
at oracle.jbo.rules.JboVCItemRequiredValidator.validate(JboVCItemRequiredValidator.java:161)
at oracle.jbo.common.ViewCriteriaImpl.validateRow(ViewCriteriaImpl.java:606)
at oracle.jbo.common.ViewCriteriaImpl.validate(ViewCriteriaImpl.java:567)
at oracle.jbo.server.ViewRowSetImpl.validateViewCriteria(ViewRowSetImpl.java:7745)
User will think that DepartmentId is required, yet only the hidden criterion of LOV is required.


But actually it is just a warning, since if I press ok and submit then the new values are submitted, even though the value of ManagerId is not valid.

If I open ManagerLOV I get again the error and the LOV opens with no data.



If I clear the value of Manager I get the error again.

This is realy confusing and makes view criteria not usable in cascading LOVs.

The workaround we do for these cases is not to use view criteria for cascading LOVs but to put conditions directly in the where clause of the query.
i.e. WHERE DEPARTMENT_ID = :inDepId

Test Case
http://adfbugs.googlecode.com/files/TestLOVwithRequiredCriterion.zip

Thanks,
Anonymous said... In this case, all you need is to set "Validation" to "Optional" and leave "Ignore Null Values" un-checked.

I tried it and works fine.

Tuesday, July 14, 2009

JDeveloper 11 r1 Cascading LOV bugs

Since I had a strange reply for the previews post in oracle forums
I decided to investigate cascading LOVs a little more

So I created a ManagersLOV view object with query:
SELECT m.EMPLOYEE_ID,
m.FIRST_NAME,
m.LAST_NAME,
m.DEPARTMENT_ID
FROM EMPLOYEES m
WHERE EXIST (select null
from employees e
where e.manager_id = m.employee_id)
I added bind variable inDepartmentId and view criteria for DepartmentId
I added it as LOV in the employees view and in the accessors I set DepartmentId as value for the bind variable.


I see in property inspector that Row Level Bind Variables is set to true.
I also added ManagerId in query Criteria
I test the application.
In query page if I select a department from LOV and then open manager LOV, managers are filtered correctly depending on department, But:
Bug 1:
If I Type a value in department (or if I remove value) and then try to select manager then the managers are not filtered correctly.


Bug 2: If I type an invalid value in Department and press search, and then try to select a manager I have a null pointer exception.:
Caused by: java.lang.NullPointerException
at oracle.adfinternal.view.faces.model.binding.FacesCtrlSearchBinding$AdfCriterionValues.(FacesCtrlSearchBinding.java:2834)


Bug 3: If I type an invalid value in Department and go to Edit page (press Edit or New) and return (New Search) tha page is corrupted with the same null pointer exception.


Bug 4: In Edit page I type an invalid value in ManagerId, then I change the department and try to select new value for the ManagerId from the LOV. But the managers are filtered according to the old department


So I think this is not correct so I go to the LOV of ManagerId field and in the UI Hints I select the checkbox Filter Combo Box Using 'ManagersLovCriteria'


I go again to the accessor and I see that property Row Level Bind Variables is empty.
I go again to the LOV of ManagerId field and in the UI Hints and I see the checkbox Filter Combo Box not checked. No mater how many times I try to check it it remains unchecked.


So I try the application and I reproduce all the above bugs.

So I manually change the value of property 'Row Level Bind Variables' to “false” and I try the application.
I cannot reproduce the Bugs 2 and 3 with NullPointerException but the Managers never filter for the selected department no mater if I select it from LOV or not

So as a conclusion, cascading LOVs don't work correctly in Jdeveloper 11g r1 no mater the value of
'Row Level Bind Variables'
Find test case application at: