7 Replies Latest reply: Feb 10, 2012 6:35 AM by Peter K RSS

    Cascading LOV

    854578
      I have a problem in which I have a couple of LOVS that attach to transient attributes - such as:

      Transient attribute 1 - model-choicelist LOV attached - appears to work correctly.

      Transient attribute 2 - model-inputTextLOV attached, LOV has bind variable that ultimately depends on Transient attribute 1.
      The lov returns 2 pieces of data the first goes into another attribute in the view object, the second the transient attribute 2 attribute.

      I cannot set Clear/Refresh value on transient attribute 2 or I get a JAG error, (getDependentItemstoClear throws exception).

      When running the two problems that appear are:
      1). After changing transient attribute 1, transient attribute 2 does not clear out - though if i bring up the model-inputTextLOV the value that is displayed within the list that is bound to transient attribute 1 has indeed changed.

      2). After choosing a new value from the model-inputTextLOV for transient attribute 2, transient attribute 2 is updated, however, the 2nd piece of data that is return never appears in another of the view objects field.

      Thank You,
      Keith
        • 1. Re: Cascading LOV
          Steven Davelaar-Oracle
          Keith,

          Can you send a testcase based on HR schema that reproduces your problem to idevcoe_nl@oracle.com?

          Steven Davelaar,
          Jheadstart Team.
          • 2. Re: Cascading LOV
            Peter K
            Thanks again, Steven.

            To summarize for forum readers what we tried (partial success here) and relate the additional problems for which we need help:

            Problem Summary
            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>"

            Additional Problems
            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?

            Thanks,
            Peter

            Edited by: Peter K on Jan 8, 2012 6:25 PM

            Edited by: Peter K on Jan 8, 2012 6:25 PM
            • 3. Re: Cascading LOV
              Peter K
              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?

              Thanks,
              Peter

              Edited by: Peter K on Jan 10, 2012 2:14 PM

              Edited by: Peter K on Jan 16, 2012 7:57 AM
              • 4. Re: Cascading LOV
                Steven Davelaar-Oracle
                Peter,

                I am not aware of any limitation.
                Can you send another testcase for the remaining issue?

                Steven Davelaar,
                JHeadstart team.
                • 5. Re: Cascading LOV
                  Steven Davelaar-Oracle
                  Peter,

                  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.

                  Steven Davelaar,
                  JHeadstart Team.
                  • 6. Re: Cascading LOV
                    Peter K
                    Steven,

                    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!

                    Peter
                    • 7. Re: Cascading LOV
                      Peter K
                      A recipe and sample implementing this technique are available on the JHeadstart blog:

                      http://blogs.oracle.com/jheadstart/entry/model_based_cascading_lovs_for