abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Ancona <...@anconafamily.com>
Subject More flexible servicesPath for ServiceProvider
Date Tue, 08 Jan 2008 15:50:19 GMT
As I mentioned in the issue I just created 
(https://issues.apache.org/jira/browse/ABDERA-85), I have a use case 
where the base URI of my service is parameterized (e.g. 
http://example.com/users/{userId}/service/). I want to use a 
ServiceProvider at the user level, i.e. I would like the servicesPath to 
match http://example.com/users/{userId}/. The current implementation in 
AbstractServiceProvider uses a plain string match, so there's no way to 
parameterize it.

I have created a class extending AbstractServiceProvider which matches 
using a regex. It also stores the match value(s) as request 
parameter(s), making them easily accessible to my CollectionProvider. 
While my class meets my needs, I think the use case is common enough 
that you might want to incorporate something similar into Abdera. I had 
to override AbstractServiceProvider.resolve() in my class, which lead to 
quite a bit of duplicated code. It might be better to:

1. Refactor AbstractServiceProvider to abstract the string matching into 
separate methods, so that classes that want to use a different matching 
method can easily do so.

2. Make the default implementation use a regex rather than a simple 
string match.

You could do either of those, or both (or neither :-)). I'm willing to 
provide a patch for whichever option(s) are preferred.

Thanks for considering this.


View raw message