Tapestry 5
  1. Tapestry 5
  2. TAP5-476

Have a common handler/filter pipeline for both component event and page render requests, to make it easier to add filters that apply to both types of requests

    Details

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

      Description

      Currently, if you want to put a filter in place that afects both types of request, you have to a contribute a ComponentEventRequestFilter to the ComponentEventRequestHandler service, and a nearly identical PageRenderRequestFilter to the PageRenderRequestHandler service.

      It would be nice if there was a service that acted as a facade around the two existing pipelines. The terminator of that pipeline could forward the request into one of the two existing pipelines.

      The common example of this is a "is logged in" filter that sends a redirect if the user is not logged in; you want to do this for both types of requests.

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open In Progress In Progress
        3h 13m 1 Howard M. Lewis Ship 27/Jan/09 18:51
        In Progress In Progress Closed Closed
        30m 27s 1 Howard M. Lewis Ship 27/Jan/09 19:21
        Howard M. Lewis Ship made changes -
        Resolution Fixed [ 1 ]
        Status In Progress [ 3 ] Closed [ 6 ]
        Fix Version/s 5.1.0.0 [ 12313428 ]
        Howard M. Lewis Ship made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Howard M. Lewis Ship made changes -
        Field Original Value New Value
        Assignee Howard M. Lewis Ship [ hlship ]
        Hide
        Howard M. Lewis Ship added a comment -

        To me "is logged on" is an application-specific concept that I don't want to hard code. Further, it quickly grows from two states (anonymous or logged-in) to multiple states (what roles or privileges does the user have).

        Show
        Howard M. Lewis Ship added a comment - To me "is logged on" is an application-specific concept that I don't want to hard code. Further, it quickly grows from two states (anonymous or logged-in) to multiple states (what roles or privileges does the user have).
        Hide
        Massimo Lusetti added a comment -

        Another long awaited feature. These could easier to add features to the chenillekit-access module. Great!

        BTW, in the context of "is logged in", doesn't sound reasonable to also make the logic to interpret the URL a service which can be reused, like by the chenillekit-access for example, so every "is logged in" module is sure to interpret the URL the correct way?

        Show
        Massimo Lusetti added a comment - Another long awaited feature. These could easier to add features to the chenillekit-access module. Great! BTW, in the context of "is logged in", doesn't sound reasonable to also make the logic to interpret the URL a service which can be reused, like by the chenillekit-access for example, so every "is logged in" module is sure to interpret the URL the correct way?
        Howard M. Lewis Ship created issue -

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development