guice servlet: capturing parts of the URIs

[GoogleCodeExporter]

I implemented a django-like named group capturing feature in guice
servlet whereas named regex groups would be saved as request
attributes.

example:
serveRegex("/myrest/<name>(.*)/<id>(.*)").with(MySerlvet.class)

this will capture the regexp groups and save the values as 'name' and
'id' request attributes

if you are interested the patch is here:
http://code.google.com/p/guice-maven/source/browse/trunk/guice_servle...

please let me know what you think

Original issue reported on code.google.com by peter.ha...@gmail.com on 19 Jul 2009 at 2:00

[GoogleCodeExporter]

sorry, this is the correct url:
http://code.google.com/p/guice-maven/source/browse/trunk/guice_servlet_named_gro
up/guice-servlet.patch

Original comment by peter.ha...@gmail.com on 19 Jul 2009 at 2:01

[GoogleCodeExporter]

This is very cool. However will this break existing regexes? =(

Original comment by dha...@gmail.com on 19 Jul 2009 at 11:13

[GoogleCodeExporter]

I do not think this would break existing code. 

if there was not any regexp group found (or the feature is not implemented yet 
ie for
normal web.xml matching), then

Map<String,Object> map =
patternMatcher.getPatternWithNamedGroups(request.getServletPath());
+     if ( map != null) {
+       for (Map.Entry<String,Object> entry: map.entrySet()) {
+         request.setAttribute(entry.getKey(),entry.getValue());
+       }
+     } 

Original comment by peter.ha...@gmail.com on 20 Jul 2009 at 6:10

[GoogleCodeExporter]

No, but isn't /myrest/<name> a valid regex?

Original comment by dha...@gmail.com on 20 Jul 2009 at 6:14

[GoogleCodeExporter]

I do not think /myrest/<name> is a valid URI (at least I have not seen <> used 
in URIs) 

Original comment by peter.ha...@gmail.com on 20 Jul 2009 at 6:23

[GoogleCodeExporter]

Hmm... I already want us to change the path dispatcher to capture the proper 
capture group; see issue 376.

Could we just add an annotated binding for the Matcher that matched the current 
servlet? Then the user can 
interpret this however he wants:
  @Provides @Named("Request ID")
  String provideRequestedId(@Named("Request Path") Matcher matcher) {
    return matcher.group(1);
  }

Perhaps this is too loose, but I'd prefer to avoid creating a metalanguage for 
servlets. That's for rich 
frameworks to do.

Original comment by limpbizkit on 20 Jul 2009 at 6:32

[GoogleCodeExporter]

I think the main difference is that in my proposed solution everything is in one
place (which was the main motivation for me),
by looking at this
serveRegex("/myrest/<name>(.*)/<id>(.*)").with(MySerlvet.class)
I know a) what's the URI to match b) what are the variable names that need to be
captured. 

Obviously it's your call though.

Originally I wanted to add my implementation on top of guice servlet but the 
whole
package is very restrictive (ie most of the things are defined as package 
private).
Would it be possible to at least open up guice servlet for extensions like this?
(Right now I need to host my patched version)

Original comment by peter.ha...@gmail.com on 20 Jul 2009 at 6:49

[GoogleCodeExporter]

When you say open up, do you mean with a before/after processor or something 
like that?

Or do you mean allowing people to plug in their own path matchers? (I can see 
us doing the latter a bit more 
easily)

Original comment by dha...@gmail.com on 20 Jul 2009 at 6:55

[GoogleCodeExporter]

in ServletModule:

 private final FiltersModuleBuilder filtersModuleBuilder = new FiltersModuleBuilder();
  private final ServletsModuleBuilder servletsModuleBuilder = new
ServletsModuleBuilder();

(on top of this, the builders are package private)

so it would be great if the builders 
(ServletsModuleBuilder,FiltersModuleBuilder)
were only protected and I could inject my own versions of ServletsModuleBuilder,
FiltersModuleBuilder and matchers.

Original comment by peter.ha...@gmail.com on 20 Jul 2009 at 7:07

[GoogleCodeExporter]

Original comment by sberlin on 22 Feb 2011 at 1:48

• Added labels: Extension-Servlet