This content has been marked as final. Show 7 replies
Can you send a testcase based on HR schema that reproduces your problem to firstname.lastname@example.org?
Thanks again, Steven.
To summarize for forum readers what we tried (partial success here) and relate the additional problems for which we need help:
We used the normal ADF BC techniques of a view criteria with bind variable, and an accessor using the view criteria and loading the bind variable based on the master LOV. We used the JHS techniques of setting Depends on Item(s) for the dependent lookup items returned from the LOVs so they would clear when the master LOV item value was changed.
We also set Clear/Refresh for the dependent lookup items to true so they would clear if a different master LOV value was selected. The JAG issued this error when all Clear/Refresh properties were set:
[WEB-INF/adfc-config-Employees.xml, default/misc/facesConfig/dependsOnItemBean.vm] Velocity log [error] Method getDependentItemsToClear threw exception for reference $item in template default/misc/facesConfig/dependsOnItemBean.vm at [18,26]
[WEB-INF/adfc-config-Employees.xml, default/misc/facesConfig/dependsOnItemBean.vm] org.apache.velocity.exception.MethodInvocationException: Invocation of method 'getDependentItemsToClear' in class oracle.jheadstart.dt.jag.pagegenerator.pgmodel.PGItemModel threw exception class java.lang.StackOverflowError : null
Unchecking that property for the first dependent item (leaving the other items set) allowed JAG to generate.
Additional Techniques Used
- In the Property Inspector for the accessors, be sure Row Level Bind Values is set to "true." Changing or just visiting the accessor editor will remove this property value so it needs to be reset each time.
- Add a EmployeesViewRowImpl class and in setLocPostalCode() -- the master LOV item -- call the setters for the dependent attributes to set them to null for example, "setDepartmentName(null);" This alone was not enough to clear the items in the View layer (although it worked in the Model layer). The Clear/Refresh JHS property for dependent items and the following needed to be used.
- Edit the adfc-config-Employees.xml file; look for the "DEPENDS_ON_ITEM_BEAN" sections (2 of them) and add the first dependent item (for which Clear/Refresh could not be set) to the existing list of items, "<value id="__901">EmployeesDeptDepartmentName</value>"
The standard use case works: the dependent LOV filters properly and values are returned to the screen for both master and dependent LOVs. The dependent item values are cleared when selecting a different master LOV value.
1. Selecting value 1 in the master LOV, then selecting a value in the dependent; then selecting a different value in the master and another in the detail -- works so far; then select the original value in the master -- the dependent LOV does not show all rows. it only shows the value first selected in the first action. Somehow that value is stuck as an additional criteria or filter.
2. The query page search fields ignore this mechanism. The LOVs appear but the view criteria filtering on the dependent LOV is not in place. Also, the lookup values are not returned to the screen as they are in the form-style page. Selecting a different master does not clear dependent values.
The JHS Dev Guide mentions that the search requires different items and LOVs and describes a technique for dynamic domains. But that JHS type of LOV cannot be mixed with the model-based LOV we have mostly working on the form-style page (as far as I can interpret the text).
Do we need to use JHS LOVs for all pages rather than model-based LOVs to achieve the cascading scenario after all?
Edited by: Peter K on Jan 8, 2012 6:25 PM
Edited by: Peter K on Jan 8, 2012 6:25 PM
Update: The answer to 2 seems to be to set the UI Hint "AutoSubmit" to true on the master LOV attribute. The model-based LOV behaves better then. Setting "AutoSubmit" to true on the dependent LOV attribute might also help for when you change the dependent attribute and the master does not match (although that needs further testing).
Update 2: Please disregard Question 1: I haven't been able to reproduce it in a new project.
But still stuck on Question 2. We have two return values for each of two LOVs, where one depends on the other. The master LOV returns both values in Advanced Search (needed to set the Dependencies property of the non-LOV item in the VO attribute UI Hints to get it to return). The dependent LOV returns only the LOV item, not the other item defines as a return. The Model tester returns both return values for both items as does an af:query component dropped into a non-JHS project.
Outside of comparing each object between those ViewController projects, does anyone have an idea of a JHS limitation regarding return items in cascading model-based LOVs?
Edited by: Peter K on Jan 10, 2012 2:14 PM
Edited by: Peter K on Jan 16, 2012 7:57 AM
I am not aware of any limitation.
Can you send another testcase for the remaining issue?
Thanks for the testcase.
The JHS version is not displaying the DepartmentId after LOV selection because it contains a quick search component which uses the same SearchRegion binding.
I think this is a bug in ADF. The work around is to create a separate ViewCriteria for the quick search component and specify this in the JHeadstart Quick Search View Criteria property.
Then JHeadstart will generate two separate SearchRegion bindings and the DepartmentId value will be displayed correctly upon LOV selection.
Yes, the workaround fixes the problem.
Additional information: You do not need to attach a view criteria to the advanced search, just to the quick search. In addition, if you turn off quick search -- set "Quick Search?" to "none" -- without a view criteria for quick search, the problem does not occur either. I guess that's just another way to prove that the problem relates to the quick search (ADF feature that quick search uses).
Many thanks, Steven!
A recipe and sample implementing this technique are available on the JHeadstart blog: