[
http://www.stripesframework.org/jira/browse/STS-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11453#action_11453
]
Andrew Jaquith commented on STS-592:
------------------------------------
Ben, thanks for looking at this. I did some detailed testing, and my findings
agreed with yours.
First, I tried using my test URL
(http://.../Godel/?do=edit¶m2=Escher¶m3=Bach) on a live servlet
container and a sample ActionBean with the binding
@UrlBinding("/clean/{param1=Test}/?do={$event}"). I got results similar to what
you found after modifying MockRoundtrip. In particular, the container extracted
three parameters, do=edit, param2=Escher, param3=Bach. That is the same as in
your tests. That, in turn, leads me to agree that I have been using
MockRoundtrip incorrectly. My mistake.
That said, I like the modification you made to MockRoundtrip (strip the query
string, parse the parameters). It gives testers a little more headroom to
"screw up" -- a good thing. A modified MockRoundtrip class would enable wider
testing on things like clean URLs. As it happens, the documentation for the
MockRoundtrip constructor that accepts an URL is not very clear. One way to fix
this is to change the documentation to say that MockRoundtrip won't work
predictably if query strings are appended. But even better, it would be great
if MockRoundtrip were be modified in the manner you described to be a little
more forgiving.
But there is a second issue here. It still seems inconsistent that "clean
URLPatterns" should allow special characters ("?" or "&") in the *generation*
of of URls, but not in the *parsing* of them. It seems to me that "?", at
least, should be allowed in URLPatterns (and therefore dealt with gracefully).
,The alternative would be to forbid them (and therefore detect and flag this
when doing the initial URLBinding annotation parsing).
Assuming the first case, I think only a small modification would be needed to
allow "?" and "*" characters in URLBindings (clean URLs). Method
trimContextPath() would need to return the context path, *plus* the query
string, for clean URL matching. Also, the URLBinding class would need to
identify if the event name is supplied as a special "event parameter" in the
URLBinding. (Simple rule of thumb: the ${event} token follows the query string
separator.) For example, URLBinding would "know" that the "do" parameter was
the one that actually contained the $event value.
I can try writing a patch for this, if you'd like.
One more thing. Any chance UrlBindingFactory could gain a public method similar
to parseUrlBinding(Class<? extends ActionBean>), but with a String parameter
instead? For example: a hypothetical parseUrlBinding(String) method would
return URLBinding prototype. Here is the use case: I would like to be able to
add URLBindings, for example, from a property file in addition to having them
parsed from class annotations. I can file a separate JIRA issue if needed.
> Stripes 1.5 URLBindingFactory does not parse clean URLs with appended
> parameters
> ---------------------------------------------------------------------------------
>
> Key: STS-592
> URL: http://www.stripesframework.org/jira/browse/STS-592
> Project: Stripes
> Issue Type: Bug
> Components: ActionBean Dispatching
> Affects Versions: Release 1.5
> Environment: OS X
> Reporter: Andrew Jaquith
>
> I've found an issue in build 947 with the implementation of clean URLs, which
> relates to differences in how the ActionResolver and UrlBuilder handle
> appended parameters. I had previously written up my observations in comments
> on STS-262, but that issue had been marked closed. I was not sure if my
> comments had been read, hence I am opening a new issue.
> Summary:
> With a given "clean" @UrlPattern, if parameters otherwise unspecified in the
> pattern are added to the UrlBuilder, they are properly appended in the
> generated URL. But if that generated URL is passed back to the StripesFilter,
> the trailing parameters are not parsed as expected, even if the ActionBean
> has properties that those parameters "should" bind do. In other words, it is
> not a "round trip" operation.
> For more in-depth comments, *and* a proposed patch to fix the issue, see
> STS-262.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
