Today, I faced an interesting issue in a dependent lov which, I thought, is worth blogging.
Normally, to create a column as lov which is dependent on another column, we create a bind variable in the child lov query, and in the main VO, we provide the parent attribute name as the value for bind variable, by editing the child view accessor.
In my scenario, a column of my table is dependent on a field which is part of a panel form layout which is present above my table.
I implemented this in the same way above and for the bind variable, I provided the value of the parent field using groovy expression.
And the table is refreshed using contextual event (my table is part of a dynamic region).
everything worked fine except one scenario!!
If I enter the parent field value first, and then create rows by clicking add row and then select lov, results are coming as expected.
If I Add row in the table first and then change the value of parent item in the form, and select lov, results are not correct. Its binding the old value and not the changed value. but if I click on add row once again, then thngs are working fine for all rows (including the previous row.)
After debugging for a while, I came to know that the only extra thing “Add Row” is doing is — it is refreshing the iterator of the table. So when the user changes the parent item, I am programmatically refreshing the iterator of my table using the following code and the lov worked fine ! 🙂
DCBindingContainer bindings = (DCBindingContainer)BindingContext.getCurrent().getCurrentBindingsEntry();
DCIteratorBinding iter = (DCIteratorBinding)bindings.findIteratorBinding("");
Perfect!….. but wait! there is one more catch here!
Lets say I added a row in lines table, but did not enter values in any field, and then changing the value of parent item.
alas! the newly added row is disappearing.
This is because when an iterator is refreshed as above, any non dirty rows will be removed.
so, further task here is to make the created rows dirty by setting some attribute in the VO.