I was recently nominated by Steve Muench and awarded with the Oracle ACE title.
I would like to thank Oracle and especially Steve for this recognition of my efforts to contribute to Oracle community my experience on Oracle products
This blog has been proven to be quite helpful to people working on ADF framework since they can find bugs and workarounds to save them time while developing fusion applications.
It has also helped to submitting bugs on Oracle Support and improving the framework,
I definitely try to do constructive criticism on the framework, as I feel very strongly about its potential and I hate to see it being compromised by implementation or occasional design issues. Fact is, there is nothing like it out there for rich client web development.
I am glad that Oracle people also see it this way and I will continue this effort to the best of my abilities.
What is a bug? especially in a framework that is used to develop applications? Is it only something that is described differently in manual? I will be writing more about that in this blog by presenting the functionality of the framework i am working on. Jdeveloper and fusion middleware
Tuesday, March 30, 2010
Wednesday, March 24, 2010
Removing a LOV return value leaves garbage in view object (Fixed in 11.1.1.4)
We had a strange bug that was really hard to find. We found some garbage in View objects that we could not find out how they were created. Yet I manage to reproduce it by removing a return value from Edit List of values wizard. In more detail :
When you have an LOV with 1 return value then the xml in the view object is like:
When you add a second return value from LOV by edit wizard:
Then the View object XML is like:
If from the same wizard I remove the second value then unfortunately the xml does not return to the initial state. It still has the DerivedAttrNames :
This causes various bugs in interface that are not easy to find, since nothing is displayed in log:
When you have an LOV with 1 return value then the xml in the view object is like:
When you add a second return value from LOV by edit wizard:
Then the View object XML is like:
If from the same wizard I remove the second value then unfortunately the xml does not return to the initial state. It still has the DerivedAttrNames :
This causes various bugs in interface that are not easy to find, since nothing is displayed in log:
Wednesday, March 17, 2010
Rollback does not refresh current row of af:table after validation errors.
In a simple af:table if you select a row and press CreateInsert then new row is created with focus above the selected row.
If you press Rollback then the selected row is by default the first row of the table.
This works fine.
Yet if before rollback you have validation errors (i.e. After creating a row, navigate to an other row), then rollback does not make the first row selected.
Selected row on table remains the last selected row even if the current row of view object is the first row.
If you press now CreateInsert, the new row is created as first row of table and it does not even have the focus.
If you click now on the empty row then you will get again the validation errors.
Is this a bug?
Test case.
http://adfbugs.googlecode.com/files/TestTableInsert.zip
Still Reproduce in jdeveloper11.1.2
SR 3-2391480761 and defect was posted for this yet it is Rejected by development team as:
Our Development team has marked this as expected behaviour and therefore it will not be fixed in the future either - at least not for now.
If you press Rollback then the selected row is by default the first row of the table.
This works fine.
Yet if before rollback you have validation errors (i.e. After creating a row, navigate to an other row), then rollback does not make the first row selected.
Selected row on table remains the last selected row even if the current row of view object is the first row.
If you press now CreateInsert, the new row is created as first row of table and it does not even have the focus.
If you click now on the empty row then you will get again the validation errors.
Is this a bug?
Test case.
http://adfbugs.googlecode.com/files/TestTableInsert.zip
Still Reproduce in jdeveloper11.1.2
SR 3-2391480761 and defect was posted for this yet it is Rejected by development team as:
Our Development team has marked this as expected behaviour and therefore it will not be fixed in the future either - at least not for now.
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
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
Subscribe to:
Posts (Atom)