[Yanel-dev] [HEADS UP] ResourceManager and ResourceConfigurationMap class may die soon; resource-types' URL matching (e.g. on request parameters)

[simon]

Guillaume Déflache schrieb:

hi guillaume

thanks for the heads up. i did miss this post.
> Some progress report as Simon showed some renewed interest in this 
> lately! ;)
> Cf. 
> http://lists.wyona.org/pipermail/yanel-development/2009-December/004192.html 
>
>
> Guillaume Déflache a écrit :
>> 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
then it would be more like this parameter="my-param-name=*" or even 
parameter-name="my-param-name" paramter-value="*".
+1 to ignore the order
>> - 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
+1 to also match POST paramters
>> - 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)
not sure about this yet.
>
> Any opinion about these issues, esp. Simon? On the 3rd I'd personally 
> go for the "match any other parameter" solution.

>
>
>> *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.)
i would welcome this.
>
> I did some (unfinished) work on this, please review the attachment.
> There is still some unfinished stuff, mainly around the TODO and XXX 
> markers, please ask me as they probably won't make any sense to anyone 
> else than me.
i still reviewing it. as far as i understand, this implements this new 
java interface you mentioned above. (ResourceTypeMatcherV1) for 
global-resource-type matching.
>
>
>> 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! ;) ).
cool
>> I'd suggest to use a better name (*Manager is rather uninspiring): 
>> org.wyona.yanel.core.api.ResourceTypeMatcherV1 maybe?
+1 for changing the name
>
> The current interface has the same name but provide 
> getResourceConfiguration(Environment environment, Realm realm, String 
> path) instead: indeed IMHO what we need to be configurable is only the 
> RC object selector, not a Resource selector (all Resource objects may 
> be instantiated in the same way for now, better not expose 
> classloading guts before we get our runtime-modularity story right).
sounds reasonable.
>
>
>> 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 
>
> That's more or less what is done in the patch.
>
>
>> 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 did not tackle that yet.
>
> We may not need to change Yanel#getResourceManager or even 
> ResourceManager to do this, as ResourceManager#getResource has already 
> the realm as parameter.
> Maybe the ResourceManager should/could become a registry of 
> ResourceTypeMatcherV1 objects for all realms, adn then we would only 
> need 
> ResourceManager#setResourceTypeMatcherForRealm(ResourceTypeMatcherV1 
> matcher, Realm realm)??? But then maybe we would only need 
> ResourceTypeMatcherV1#getResourceConfiguration(Environment 
> environment, String path) without the realm parameter? 
don't got the picture yet. need to look at the source and think more.
>
> Or maybe we should wait and do that in ResourceTypeMatcherV2?
>
>
>> 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 
>
> This still can/should be done once dust has settled on all things above.
>
>> needs changing because Michi would like to be able to parametrize the 
>> "map.rc-map" file name.
>
>
> This will probably be left as an exercise to casual contributors! :P
let's see ;)

cheers
simon
>
>
> Cheers,
>    Guillaume