Details

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

      Description

      Provide an application page interceptor / listener facility into Click. The concept is to provide an extension point for code which can listener to key page events and also interrupt normal page processing flow.

      Using this code which tends to be incorporated into Page superclasses can be refactored into listener classes which can be reused in applications. This approach supports Page design by composition, rather than through inheritance.

      Page listeners could be used for:

      • enforcing an application wide security polity, rather than using the Page#onSecurityCheck() method
      • dependency injection, see CLK-581
      • support page performance profiling and logging

      The listener interface would be:

      public interface PageInterceptor

      { boolean pageCreate(Class<? extends Page> pageClass, Context context); boolean postCreate(Page page); boolean preResponse(Page page); void postDestroy(Page page); }

      Application page interceptor classes would be defined in the click.xml configuration file. Applications could defined multiple interceptor which would be executed sequentially in the order in which there are defined. Lnterceptor could have a scope / lifecycle of request (where by new instances are created for each page request, and are threadsafe), or application (where by a single instance is created and used for all page requests). interceptor can also be configured to have properties which are set after creation. This scope rules equates to Spring prototype and singleton scopes.

      An example configuration is provided below:

      <page-interceptor classname="com.mycorp.listener.ProfilingInterceptor"/>

      <page-interceptor classname="com.mycorp.listener.SecurityInterceptor" scope="application">
      <property name="notAthenticatedPath" value="/login.htm"/>
      <property name="notAuthorizedPath" value="/not-authorized.htm"/>
      </page-interceptor >

        Activity

        Hide
        sabob Bob Schellink added a comment -

        Hi Malcolm,

        This looks really interesting. Personally I think calling it PageInterceptor is more appropriate though.

        kind regards

        bob

        Show
        sabob Bob Schellink added a comment - Hi Malcolm, This looks really interesting. Personally I think calling it PageInterceptor is more appropriate though. kind regards bob
        Hide
        medgar Malcolm Edgar added a comment -

        OK with PageInterceptor for a name. This will also help differentiate the concept for control listeners.

        Show
        medgar Malcolm Edgar added a comment - OK with PageInterceptor for a name. This will also help differentiate the concept for control listeners.
        Hide
        sabob Bob Schellink added a comment -

        Wonder if this functionality could be extended to a Control as well. In ClickClick I needed something similar: the ability to "intercept" certain events to add Ajax functionality to controls. Currently this is solved through a custom EventDispatcher that can fire listeners beforeOnProcess and beforeResponse. However the idea of an interceptor is semantically more correct than a listener for this scenario.

        One issue with a ControlInterceptor is that we don't have full control over the control lifecycle. For example, controls are created and added by the developer, not by the framework so we won't be able to intercept all events such as onInit. However the more interesting interception points are beforeOnProcess and beforeOnResponse.

        Show
        sabob Bob Schellink added a comment - Wonder if this functionality could be extended to a Control as well. In ClickClick I needed something similar: the ability to "intercept" certain events to add Ajax functionality to controls. Currently this is solved through a custom EventDispatcher that can fire listeners beforeOnProcess and beforeResponse. However the idea of an interceptor is semantically more correct than a listener for this scenario. One issue with a ControlInterceptor is that we don't have full control over the control lifecycle. For example, controls are created and added by the developer, not by the framework so we won't be able to intercept all events such as onInit. However the more interesting interception points are beforeOnProcess and beforeOnResponse.
        Hide
        sabob Bob Schellink added a comment -

        fixed

        Show
        sabob Bob Schellink added a comment - fixed
        Hide
        a_adrian Adrian A. added a comment -

        closing issue fixed a long time ago

        Show
        a_adrian Adrian A. added a comment - closing issue fixed a long time ago

          People

          • Assignee:
            medgar Malcolm Edgar
            Reporter:
            medgar Malcolm Edgar
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development