[Registry-dev] Handlers

[Glen Daniels]

Cool, thanks Chathura!

I have a couple of tweaks I'd like to make to what you ended up with, 
but I need to noodle on them a little more.  Will write them up in 
detail in the morning (your evening).  One thing I'll say now is that 
I'd still like Handler/Filter to be interfaces - rather than pushing 
data into abstract classes, I think it's cleaner if the implementations 
pull it from the RequestContext as needed.

--Glen

Chathura C. Ekanayake wrote:
> 
> 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
>>
> 
> 
> _______________________________________________
> Registry-dev mailing list
> Registry-dev at wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>