[Registry-dev] Handlers

[Chathura C. Ekanayake]

I implemented the new handler model as discussed.

Minor change from the discussed design is that the Filter class has 
methods to match all actions supported by the handlers.

public abstract class Filter {
  
    public abstract boolean handleGet(RequestContext requestContext) 
throws RegistryException;

    public abstract boolean handlePut(RequestContext requestContext) 
throws RegistryException;

    ...
}

handleGet(...) method determines whether the associated handler can 
handle the get action. handlePut(...) method determines whether the 
associated handler can handle the put action. This is necessary as the 
criteria for invoking a handler may differ based on the action.

Also both Handler and Filter are implemented as abstract classes instead 
of interfaces as there are some common functionality and attributes 
required for all instances.

Thanks,
Chathura


Glen Daniels wrote:
>
> Hi Devs:
>
> There's been some backchannel conversation recently about our plug
> points, which I wanted to summarize and bring to the dev list.  This
> message is about merging media-type and URL handlers, and the next one
> will be about events.
>
> The general idea is this - there should be a single plugin which
> encompasses the functionality of our current MediaTypeHandlers and
> URLHandlers.  In many cases we want to enable users to add
> media-type-specific handling, but only for particular areas of the URL
> space (i.e. "/myDepartment/WSDLs").  And we've been discussing use cases
> for workflows and lifecycles that would require plugins to react to
> other data such as property values - and again we want to let different
> sets of these plugins deal with different areas of the hierarchy.  Also
> there may be multiple plugins that want to run for a given interaction.
>
> So here's a sketch of what we're talking about here:
>
> interface Handler {
>   void put(RequestContext context) throws RegistryException;
>   Resource get(RequestContext context) throws RegistryException;
>   void delete(RequestContext context) throws RegistryException;
> }
>
> I'm assuming here that the RequestContext contains pointers to the
> Registry, the new resource (for put()), the target URL, etc. (clearly
> this will need to be fleshed out).
>
> Then we have the mechanism we use to match requests to handlers:
>
> interface Filter {
>   boolean match(RequestContext context);
> }
>
> And this is how you get handlers registered:
>
> Registry {
>   void addHandler(Filter conditions, Handler handler);
> }
>
> So here's a simple example where we want to spell-check every text
> document inserted under "/myDepartment/" in the Registry...
>
> // Filter can be a single condition...
> conditions = new URLMatcher("/myDepartment/*");
> // or multiple ones in a chain...
> conditions = new FilterSet().add(conditions).
>                   add(new MediaTypeMatcher("text/plain");
> registry.addHandler(conditions, new SpellChecker());
>
>
> It's true we could also have one set of Handlers that always runs, and
> each of them deals with deciding on its own if it should do anything
> based on the context.  I separated out the Filter mechanism for a couple
> of reasons; 1) this lets Handler authors be more generic, so a given
> Handler can be used in multiple situations, and 2) even though an
> initial implementation might be very "brute force", we can evolve it to
> do cool things like precompile a given set of Filters into a very
> efficient processing engine (esp for URL regexps) - if the Filters
> weren't separate that wouldn't be possible later.
>
> Thoughts / comments?
>
> Thanks,
> --Glen
>
> _______________________________________________
> Registry-dev mailing list
> Registry-dev at wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>