You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by "Jim Ancona (JIRA)" <ji...@apache.org> on 2008/01/09 19:21:34 UTC
[jira] Created: (ABDERA-86) More flexible servicesPath for
ServiceProvider
More flexible servicesPath for ServiceProvider
----------------------------------------------
Key: ABDERA-86
URL: https://issues.apache.org/jira/browse/ABDERA-86
Project: Abdera
Issue Type: New Feature
Affects Versions: 0.4.0
Reporter: Jim Ancona
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ABDERA-86) More flexible servicesPath for
ServiceProvider
Posted by "Jim Ancona (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ABDERA-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Ancona updated ABDERA-86:
-----------------------------
Attachment: AbstractServiceProvider_regex.patch
A patch to make the default implementation use a regex rather than a simple string match. Refactoring to make the match method replaceable looked like more than I had time to take on at the moment.
I also updated CollectionProviderTest so that it sets a regex pattern in the ServiceProvider.
> More flexible servicesPath for ServiceProvider
> ----------------------------------------------
>
> Key: ABDERA-86
> URL: https://issues.apache.org/jira/browse/ABDERA-86
> Project: Abdera
> Issue Type: New Feature
> Affects Versions: 0.4.0
> Reporter: Jim Ancona
> Attachments: AbstractServiceProvider_regex.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ABDERA-86) More flexible servicesPath for
ServiceProvider
Posted by "James M Snell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ABDERA-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James M Snell resolved ABDERA-86.
---------------------------------
Resolution: Fixed
Fix Version/s: 0.4.0
With the server refactoring and the introduction of RouteManager, I believe this is dealt with. Please confirm.
> More flexible servicesPath for ServiceProvider
> ----------------------------------------------
>
> Key: ABDERA-86
> URL: https://issues.apache.org/jira/browse/ABDERA-86
> Project: Abdera
> Issue Type: New Feature
> Affects Versions: 0.4.0
> Reporter: Jim Ancona
> Fix For: 0.4.0
>
> Attachments: AbstractServiceProvider_regex.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ABDERA-86) More flexible servicesPath for
ServiceProvider
Posted by "Dan Diephouse (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ABDERA-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558043#action_12558043 ]
Dan Diephouse commented on ABDERA-86:
-------------------------------------
Looks like good stuff. I'm really more swamped than I want to be this weekend. I'll apply this as soon as I can though.
> More flexible servicesPath for ServiceProvider
> ----------------------------------------------
>
> Key: ABDERA-86
> URL: https://issues.apache.org/jira/browse/ABDERA-86
> Project: Abdera
> Issue Type: New Feature
> Affects Versions: 0.4.0
> Reporter: Jim Ancona
> Attachments: AbstractServiceProvider_regex.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.