1 Reply Latest reply: Feb 11, 2013 8:35 PM by Chris Muir-Oracle RSS

    How to obsolete some parameters in a TF

      Hi Folks
      We have a TF which is consumed by lets say various teams.
      Now in V1 we have the TF lets say with parameter:
      a) P1

      Consuming team uptook the TF and provided the values to the TF parameter in there page defs.
      ( They have code in their backing bean.)
      So far everything is fine.

      Now lets say we want to remove param "P2" . We can remove it from our TF and the latest jar is consumed by our consumer.
      However we do not want that each consumer has to go and modify their respective page defs to remove the parameter "P2" which is no longer needed.
      Basically we want this in a such way that consumer does not have to bother for the parameters which got removed.
      Will ADF be intelligent enough to realize that parameter P2 is no longer required and thus not execute the code behind that parameter on Consumer side?
      Is there a way to achieve this?
      ( Right now we see that the code behind param2 get executed as its still part of the page def.)

      regards and thanks
        • 1. Re: How to obsolete some parameters in a TF
          Chris Muir-Oracle
          Hi Amish

          In this regards task flows they are no different from 3GL functions and the same issues of the stability of the functions API applies. If you change the functions API/signature, you affect all the callers.

          However some rudimentary testings shows:

          a) If you remove the parameters from a fragment based task flow, but leave the parameters in the task flow bindings of the calling page, the excess parameters are just ignored.

          b) In the similar case of calling a page based task flow via a task flow call, the task flow still runs. However the task flow call does flag that it doesn't recognize the deleted parameter that still embedded in the task flow call.

          I wont test it as I suspect the result will be the same, but there's also a third way of passing parameters using a parameterMap.

          Of course you could test all of this yourself with some simple examples to verify what I've said here and to reassure yourself that your strategy would work.

          Note that I've tested all of this under, and there's no guarantees in the future Oracle wont change the implementation such there is a runtime check to enforce the excess parameters aren't removed.