Tapestry
  1. Tapestry
  2. TAPESTRY-1724

Add ability for pages to be notified about errors within themselves so that they can override the default error handling behavior

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.0.5
    • Fix Version/s: 5.0.9
    • Component/s: tapestry-core
    • Labels:
      None

      Description

      It would be nice if there was a way pages could define an event handler that would be notified in the event of an exception while processing the page; it should be passed the exception and some indicator (an enum) of where the exception occurred. This would allow a way for individual pages to handle certain exceptions in a specific way.

      A particular use case for this would be handling the case where parameters can not be coerced when invoking an activate event handler method, but there's quite likely many others.

        Activity

        Howard M. Lewis Ship created issue -
        Howard M. Lewis Ship made changes -
        Field Original Value New Value
        Assignee Howard M. Lewis Ship [ hlship ]
        Howard M. Lewis Ship made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Hide
        Daniel Jue added a comment -

        This could also be a round-about solution for form submissions that reference an expired session. Not sure if this happens in Tapestry natively, but when using Acegi, if you submit a form from an expired session, you will get an error page after being forced to log in again.

        Since Acegi is usually site wide, we would still want to use some kind of custom URL request filter (tell Acegi to use it in it's config) and strip form variables.

        But it would be nice for any page to grab a hold of an error and handle it in a page-specific way.

        Show
        Daniel Jue added a comment - This could also be a round-about solution for form submissions that reference an expired session. Not sure if this happens in Tapestry natively, but when using Acegi, if you submit a form from an expired session, you will get an error page after being forced to log in again. Since Acegi is usually site wide, we would still want to use some kind of custom URL request filter (tell Acegi to use it in it's config) and strip form variables. But it would be nice for any page to grab a hold of an error and handle it in a page-specific way.
        Howard M. Lewis Ship made changes -
        Summary Way for pages to intercept errors easily Add ability for pages to be notified about errors within themselves so that they can override the default error handling behavior
        Description It would be nice if there was a way pages could define an event handler that would be notified in the event of an exception while processing the page; it should be passed the exception and some indicator (an enum) of where the exception occured. This would allow a way for individual pages to handle certain exceptions in a specific way.

        A particular use case for this would be handling the case where parameters can not be coerced when invoking an activate event handler method, but there's quite likely many others.
        It would be nice if there was a way pages could define an event handler that would be notified in the event of an exception while processing the page; it should be passed the exception and some indicator (an enum) of where the exception occurred. This would allow a way for individual pages to handle certain exceptions in a specific way.

        A particular use case for this would be handling the case where parameters can not be coerced when invoking an activate event handler method, but there's quite likely many others.
        Howard M. Lewis Ship made changes -
        Fix Version/s 5.0.9 [ 12312930 ]
        Resolution Fixed [ 1 ]
        Status In Progress [ 3 ] Closed [ 6 ]
        Mark Thomas made changes -
        Workflow jira [ 12411769 ] Default workflow, editable Closed status [ 12568392 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12568392 ] jira [ 12591449 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open In Progress In Progress
        145d 18h 2m 1 Howard M. Lewis Ship 22/Jan/08 17:57
        In Progress In Progress Closed Closed
        1d 2h 23m 1 Howard M. Lewis Ship 23/Jan/08 20:21

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Howard M. Lewis Ship
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development