[Yanel-dev] [HEADS UP] ResourceManager and ResourceConfigurationMap
class may
die soon; resource-types' URL matching (e.g. on request parameters)
Guillaume Déflache
guillaume.deflache at wyona.com
Wed Jun 24 09:59:39 CEST 2009
Hi!
As discussed with Simon some time ago (unfortunately no one took notes
:(...) we would like to be able to choose the resource-type to use for a
request by matching the value or presence of HTTP request parameters
(ATM one can only match on the request URI).
As far as Michi and I can remember, we then considered at least 2 options:
*Option 1*: allow a syntax similar to "**?my-param-name=*" in map.rc-map
files in "matcher" elements for the "pattern" attribute.
Some issues:
- most probably we want to ignore the order of the request parameters as
they are written in the pattern, as anyway AFAIK the servlet spec does
not define it
- should we also match parameters passed through POST, albeit the syntax
of the pattern could make use think it would only work for GET: Mich and
I would say we should, and the servlet API makes that choice easier
- what would "**" mean in the query string part? I'd suggest it should
either throw some parsing exception, or match any other parameter that
could also be present (would allow use to distinguish between the two
cases "only these parameters" and "these parameters and some others we
do not care about", although that might be somewhat counter-intuitive)
*Option 2*: allow full customization of the matching policy by
introducing a new Java interface for it.
(1st please note that #1 can readily be implemented independently of #2
but of course we'd rather put new functionality in the new places if
possible.)
This interface would be almost identical to the
org.wyona.yanel.core.ResourceManager class's (minus the deprecated
parts) and especially provide getResource(Environment environment, Realm
realm, String path, ResourceConfiguration rc): having access to the
environment should allow any future kind of matching imaginable (see
Apache Cocoon for wild ideas! ;) ).
I'd suggest to use a better name (*Manager is rather uninspiring):
org.wyona.yanel.core.api.ResourceTypeMatcherV1 maybe?
Then as 1st step we would have to reimplement
org.wyona.yanel.core.ResourceManager using the new interface and still
use it as the default for backward-compatibility.
Then we would have to allow configuration of the concrete matching
class. ATM this is done in the Yanel class, but Michi would like it to
be configurable per realm, and thanks to the way it's currently
encapsulated there this is also possible only with some more
deprecations (namely Yanel.getResourceManager).
I'd also suggest we hide functionality actually in
ResourceConfigurationMap in the concrete matcher implementations: the
class only has static methods and needlessly expose mechanics. It also
needs changing because Michi would like to be able to parametrize the
"map.rc-map" file name.
WDYT?
Cheers,
Guillaume
More information about the Yanel-development
mailing list