2 Replies Latest reply: May 19, 2013 4:24 AM by Jan Vervecken RSS

    so problems can be handled locally inside a task flow

    Jan Vervecken
      hi

      Please consider the Oracle Magazine article "Catch Me If You Can " by Frank Nimphius
      at http://www.oracle.com/technetwork/issue-archive/2013/13-mar/o23adf-1897193.html

      In the section "Unbounded Task Flow: Oracle ADF Controller Error Handling " it says
      "... Still, there is an issue to fix. ... The error handling, however, is not in the bounded task flow but in the unbounded task flow, ... To avoid this and follow Oracle ADF best practices, you should define error handler activities in all bounded task flows so problems can be handled locally inside a task flow. ..."

      And in the section "Custom Oracle ADF Model Error Handler" it says
      "There is only one Oracle ADF Model error handler active for an Oracle ADF application. For this reason, a custom Oracle ADF Model error handler should be configured only in the DataBindings.cpx file of the application and never in bounded task flows deployed as Oracle ADF libraries. "

      - (q1) Why does the "... so problems can be handled locally inside a task flow ..." idea (of encapsulation) apply only to ADF Controller error handling and not to ADF Model error handling?

      (Sure it might be what the framework currently does, but question (q1) is more to consider why it is designed like that.)

      many thanks
      Jan Vervecken
        • 1. Re: so problems can be handled locally inside a task flow
          Frank Nimphius-Oracle
          - (q1) Why does the "... so problems can be handled locally inside a task flow ..." idea (of encapsulation) apply only to ADF Controller error handling and not to ADF Model error handling?

          Good question. Let me try an dexplanation.

          From a design perspective, DataBindings.cpx files are merged at runtime to one instance at runtime (there always is a single BindingContext at runtime), which is why the error handler defined in an ADF library would cause a conflict with the one defined in the base application if loaded instead. The Error handler in DataBinding.cpx is comparable to the global task flow exception handler (https://blogs.oracle.com/jdevotnharvest/entry/extending_the_adf_controller_exception_handler) which also there is only one instance at a time and not to the error handler activity in a task flow (which is a control flow logic).

          I think a challenge for modularizing the binding context error handler would be to tell which error handler class needs to be referred to to handle an exception unless there is a traceable relationship between the "exception & error code", the data control and the DataBindings.cpx file containing the error handler class reference. I could imagine that if this relationship would exist then a delegation pattern could be used to handle this. However, exceptions that are spawned by the business model don't know about the DataControl exposing it (or the DataBindings.cpx file). Not sure if there is a good solution to this or if there is a real requirement for it.

          I think that what I describe in the article should maybe be filed as an ER/Bug to strip out or ignore ErrorHandler defintiions in DataBindings.cpx files that are not in the base application to avoid confusion, which would require the class loader to know which file is the one that needs to be parsed first

          Frank
          • 2. Re: so problems can be handled locally inside a task flow
            Jan Vervecken
            Thanks for your reply Frank.

            Maybe I have missed something in the explanation you try, but I don't think it answers the "why" in my question (q1).

            Maybe I should try to ask a different, but related, question focusing more on the encapsulation idea (or the "API of a bounded task-flow" if you will).

            In this context it could help to think of a bounded task-flow as a (service) method-call, as some sometimes make a comparison saying "... The implementation of the task flow - like in Web Services - is a detail that only the developer of the task flow need to know ..." [1].

            - (q2) Is it possible to create an ADF bounded task-flow that (catches and) handles every possible exception that is caused (thrown) in its own implementation? So, (catching and) handling all exceptions related to model, view, controller or whatever, "encapsulating" the exception aspect?
            Frank Nimphius wrote:
            ... Not sure if there is a good solution to this or if there is a real requirement for it. ...
            The question (q2) illustrates a potential real (and general) requirement.

            - [1] at Re: mutual dependent task-flows

            thanks
            Jan Vervecken