3 Replies Latest reply: Nov 15, 2003 9:24 PM by 408151 RSS

    9.0.5 ADF/UIX tableSelection question

    408151
      I'm confused about the behavior of tableSelection in a simple UIX form. Drop a table (EMP) into a UIX form as "Read-Only Table". Then drop in below it a "Read-Only Form" from the same table / VO. Run the form.

      Clicking on "Next", etc. properly moves the "Select" radio button current row indication in the read-only table. But clicking directly on a different radio button in the table does not change the data in the read-only table below. This is the expected behavior.

      How can I easily implement this behavior?

      Things get really messy when a "Input Form" (with or without Navigation) is used. Clicking on a row's radio button in the read-only table overwrites that row's data with the previously selected row's data as soon as the user clicks the radio button for any other row...hmmm! What I want is for the "Input Form" to be populated with the data for the newly selected row (when clicking the radio button for that new row).

      Am I missing something?

      Cheers,

      --Douglas
        • 1. Re: 9.0.5 ADF/UIX tableSelection question
          408151
          CORRECTION:

          ...clicking directly on a different radio button in the table does not change the data in the read-only form below.

          After a little more experiementation I found that doing a drop as "Master Detail" provides the behavior I'm looking for with a read-only form. With a little more playing around I also got it to work with an input form. Here's what I found... I'd still love to get the $0.02 from the "experts".

          1) A line must be manually added to the handler for the "goto" event ((What does this do exactly?!?)):
          <set property="currentRowIndexInRange"
               target="${data.ViewEmpUIModel.EmpView1Iterator}"
               value="${0}"/>
          2) An id must be manaually added to the element containing the fields (read-only form, or input form), which must match one of the targets specified in the firePartialAction of the singleSelection's primaryClientAction:
           <tableSelection>
            <singleSelection selectedIndex="${data.EmpUIModel.EmpView1Iterator.currentRowIndexInRange}">
             <primaryClientAction>
              <firePartialAction event="select" source="EmpView10" targets="test"/>
             </primaryClientAction>
            </singleSelection>
           </tableSelection>
          I guess the real question becomes: Why isn't this the default drag & drop behavior?

          Cheers,

          --Douglas
          • 2. Re: 9.0.5 ADF/UIX tableSelection question
            101342
            Yes, as you say, "Master Detail" provides (most of) what you want. If you try to drop this in with two drops, we don't know that the two are supposed to be associated.

            The <set> in the "goto" here indicates that - since you've navigated to a new group - you don't want to be pointing to the old selection, but to the first row of the new block in your table. This is zero-indexed land, hence value="${0}".

            The primaryClientAction on the singleSelection, as you already figured out, says which parts of the page to update when clicking on the selection of the table.

            We definitely agree that this sort of thing should be more automatic. So, for instance, it'd be much better if we recognized that the input form of your page was going to have to change as the selected row changed, instead of forcing you to include a <firePartialAction> and explicitly say so. But This is tricky stuff to get right (and potentially slow code to execute), so, for now, an action has to say so explicitly.

            Hope this helps.
            • 3. Re: 9.0.5 ADF/UIX tableSelection question
              408151
              Hi Adam. Awesome. TFTI (thanks for the information)

              --Douglas