RE: [Springframework-developer] PathMatchingUrlHandlerMapping

[Alef A. \(JTeam\) <al...@jt...>]

Ok, I placed the PathMatcher in web.util, but you're right, I'll
refactor it into the general util package. I'll send the zip again when
it's finished...

Alef


-----Oorspronkelijk bericht-----
Van: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Verzonden: Monday, July 14, 2003 4:07 PM
Aan: Rod Johnson; al...@jt...;
spr...@li...
Onderwerp: RE: [Springframework-developer] PathMatchingUrlHandlerMapping


Alef,

I've just browsed your code, and already intended to suggest to refactor
the path matching stuff into a com.interface21.util.PathMatcher or the
like, as it doesn't depend on handler mappings or even servlet classes.
So fine, go ahead! I really welcome more flexible path resolution
options. Guess why SimpleUrlHandlerMapping is called "simple"... ;-)

Regarding unified configuration: I actually gave some thoughts to this,
but didn't reach any conclusion. The role of a HandlerMapping is to
resolve a handler (i.e. Controller), while the role of a
MethodNameResolver is to resolve a method within a certain handler (i.e.
MultiActionController). As the latter can also work via explicit
"action" parameter etc, I don't think we should mix these roles.

I added a "...*" mapping to AbstractUrlHandlerMapping (thus both
BeanNameUrlHandlerMapping SimpleUrlHandlerMapping) some weeks ago,
mainly to enable a single "/mymulti/*" mappings to a
MultiActionController that can map sub paths like "/mymulti/myactionX"
to its methods then. Previously, one had to repeat all those
method-level mappings one-by-one on the HandlerMapping.

Of course, it makes sense to have similar path matching options on both!

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Monday, July 14, 2003 3:49 PM
To: al...@jt...; spr...@li...
Cc: j=FCrgen h=F6ller [werk3AT]
Subject: Re: [Springframework-developer] PathMatchingUrlHandlerMapping


It certainly would be handy for method name resolution. We need
consistency between these two things. Juergen, did you give any thought
to having one config handle both by default somehow?

Regards,
Rod

----- Original Message -----
From: "Alef Arendsen (JTeam)" <al...@jt...>
To: "'Rod Johnson'" <rod...@in...>;
<spr...@li...>
Sent: Monday, July 14, 2003 2:50 PM
Subject: RE: [Springframework-developer] PathMatchingUrlHandlerMapping


> Wait!!!  ;-)
>
> Right now I'm noticing that this functionality would also be verrrry=20
> handy for the methodname resolver...
>
> So I'll have to abstract the PathMatching stuff into a separate class=20
> (which makes testing even easier probably) and extend (probably) the=20
> PropertiesMethodNameResolver thingy as well...
>
> So if no objections here, I'll go ahead and do that as wel...
>
> Alef
>
>
> -----Oorspronkelijk bericht-----
> Van: Rod Johnson [mailto:rod...@in...]
> Verzonden: Monday, July 14, 2003 3:37 PM
> Aan: al...@jt...; spr...@li...
> Onderwerp: Re: [Springframework-developer]=20
> PathMatchingUrlHandlerMapping
>
>
> This is very useful functionality. Good work!
>
> Thanks,
> Rod
>
> ----- Original Message -----
> From: "Alef Arendsen (JTeam)" <al...@jt...>
> To: <spr...@li...>
> Sent: Monday, July 14, 2003 2:38 PM
> Subject: [Springframework-developer] PathMatchingUrlHandlerMapping
>
>
> > Hi all,
> >
> > Since I work a lot with protected resources and stuff in webapps,=20
> > but on the other hand want to share and reuse different view across=20
> > multiple protected resources, I've implemented a somewhat more=20
> > advanced UrlHandlerMapping, one that kind of shows the behavior the=20
> > Ant patterns functionality also has, so:
> >
> > /**/view/listView.jsp for instance would both match on=20
> > /user/view/listView.jsp, but also on /admin/view/listView.jsp=20
> > /**/view/listView?.jsp for isntance would both match on=20
> > /user/view/listViewA.jsp but also on /admin/view/listViewB.jsp=20
> > /*view*.jsp for instance would both match on /view.jsp both also on=20
> > /view-employee.jsp and /detailed-view-employee.jsp
> >
> > I've included the additions and modifications I needed to do. These=20
> > are the following:
> >
> > *** Addition of PathMatchingUrlHandlerMapping
> > This class is extending SimpleUrlHandlerMapping and overrides the
> > lookupHandler() method from AbstractUrlHandlerMapping
> > *** Modification of AbstractUrlHandlerMapping
> > Because from the overriden lookupHandler() method I need to be able=20
> > to
>
> > inspect handlerMap property from the AbstractUrlHandlerMapping, I=20
> > made
>
> > this property protected instead of private
> > *** Addition of PathMatchingUrlHandlerMappingTestSuite and map3.xml=20
> > to
>
> > this package which is testing the PathMatchingUrlHandlerMapping
> >
> > I've been running the Clover stuff and managed to get the coverage=20
> > up to 87,2%, I hope that's up to standards for you guys?
> >
> > About the pathmatching principles, they're explained in the JavaDoc=20
> > of
>
> > the class itself. The algorithms are 'borrowed' from the Ant=20
> > SelectorUtils class. I've modified them to use Lists instead of=20
> > Vectors.
> >
> > It would be nice if you would be able to integrate them.
> >
> > Cheers,
> >
> > Alef Arendsen
> >
>
>