Some 'more, in-depth' information on Oracle BPEL PM, ESB and other SOA, day2day things

Wednesday, July 14, 2004

ADF in the house - some tricks for solving common issues, Part I

Well,
after we solved the first issues that arised with our new ADF Framework, we're on track -> with building demo app*s for our ct*s.

A common problem, well known from BC4J development, is about having VO*s for navigation - and use the same definitions, but different instances of them for updating records.

Imagine the following:
  • In the AM datamodel EmpVO is a detail of DeptVO (which means setting a current row in Dept, syncs down to the EmpVO and filters the rowset), and this construct is used for navigation too - Now you want to re-locate an employee to a new Dept (as you are in "Edit mode"), from a bc4j perspective, nothing easier then that, BUT in your ADF app, the whole thing behaves little different, in case you don't want to start writing code in your DataActions


  • When you looked into to ADF Tutorials on OTN there's a nice one, describing how to create an Edit form, with the setCurrentRowWithKey Action Forward.
    This action foward does "nothing" more then finding the row you choose with the findByKey method (of oracle.jbo.ViewObject) and sets it current in the VO, the iterator you use is based on. So what's the trick to get this done?

    From the UIModel the page uses - this is the setCurrentRowWithKey Action-Binding:
    <DCControl
       id="setCurrentRowWithKey"
       SubType="DCMethodAction"
       IterBinding="DepartmentsView1Iterator"
       Action="999"
       RequiresUpdateModel="true"
       DataControl="HRModuleDataControl"
       InstanceName="DepartmentsView1Iterator"
       MethodName="setCurrentRowWithKey"
       ReturnName="HRModuleDataControl.methodResults.setCurrentRowWithKey"
       IsLocalObjectReference="true" >
       <Contents>
          <NamedData
             NDName="Arg0"
             NDType="java.lang.String"
             NDOption="2"
             NDValue="%null%" >
          </NamedData>
       </Contents>
    </DCControl>

    - So when using this action forward, what's happening?
  • The row you choose from your Iteratorbinding DepartmentsView1Iterator, is put as the current one in InstanceName DepartmentsView1Iterator, which is in general the thing you want to achieve, except in the case we're talking about here.
    So the trick to get the row current in another VO, is just creating a new IteratorBinding in your UIModel, that points to the VO instance you want to have the row the current one, and change the InstanceName to this new Iterator, and voila it's done.


  • Btw. just wanted to thank Steve, our fellow PM for BC4J and other stuff, for explaining me some in depth issues, how our binding model works, that helped for this article :-)

    Having questions? Feedback me on this entry ADF in the house, tips 'n' tricks

    0 Comments:

    Post a Comment

    << Home