Sounds good.
I think handlers need to be activated in more methods other than the
put, get and delete. Current media type handlers support the events
importResource, putChild and importChild in addition to above methods.
Handlers can support rename event as well.
Another thing we have to think about when refactoring handlers is the
API available for handler authors. Currently they get the Registry API,
User manager API and a reference to the Registry data source. Registry
data source is made available so that handler authors can query and
combine data in any required way to perform actions not exposed through
the Registry API. To make it more convenient we can write some utility
classes to perform many common operations and made them available to
handler authors. But I think giving a reference to the data source is
also necessary to give them complete flexibility.
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
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
_______________________________________________
Registry-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
