guice servlet: capturing parts of the URIs

[gissuebot]

From peter.hausel on July 19, 2009 10:00:32

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: https://code.google.com/p/guice-maven/source/browse/trunk/guice_servle.. .

please let me know what you think

Original issue: http://code.google.com/p/google-guice/issues/detail?id=405

[gissuebot]

From peter.hausel on July 19, 2009 07:01:29

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

[gissuebot]

From dhanji on July 19, 2009 16:13:34

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

[gissuebot]

From peter.hausel on July 19, 2009 23:10:38

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()); +       } +     }

[gissuebot]

From dhanji on July 19, 2009 23:14:11

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

[gissuebot]

From peter.hausel on July 19, 2009 23:23:48

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

[gissuebot]

From limpbizkit on July 19, 2009 23:32:25

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.

[gissuebot]

From peter.hausel on July 19, 2009 23:49:19

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)

[gissuebot]

From dhanji on July 19, 2009 23:55:46

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)

[gissuebot]

From peter.hausel on July 20, 2009 00:07:18

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.

[gissuebot]

From sberlin on February 21, 2011 17:48:17

(No comment was entered for this change.)

Labels: Extension-Servlet