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

        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