[
http://www.stripesframework.org/jira/browse/STS-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12363#comment-12363
]
Carl Krig commented on STS-839:
-------------------------------
Ah but I was thinking of something similar to
http://www.voddler.com/en/movie/browse/, where you can actually input the
go-to-what-page-number and press enter;
Page [_45_] of 123
where [_45_] is a <input type="text" value="45"/> (or <stripes:text
name="pageNumber" onkeypress="...">, or you could add the event handler using
jquery). Not just a <a> (<stripes:link>), that is.
The baked url becomes /browser/someX/otherY?pageNumber=42 and I really like the
way stripes:param just makes everything pretty (SEO-friendly) and neat.
Another workaround that would give
/browser?some=someX&other=otherY&pageNumber=42 (not so pretty, not so neat) is;
<form action="/browser" method="get">
<input type="hidden" name="some" value="${actionBean.some}"/>
<input type="hidden" name="other" value="${actionBean.other}"/>
<input type="text" name="pageNumber" value="${actionBean.pageNumber}"
onkeypress="javascript:if (window.event.keycode == 13 || event.which == 13)
this.parent.submit();"/>
</form>
Still, the only reason we started using UrlBinding was to get pretty
(SEO-friendly) urls like /browser/someX/otherY?pageNumber=42 and we'd reallly
like to stick with those, even when it doesn't matter SEO-wise, instead of
mixing with /browser?some=someX&other=otherY&pageNumber=42
Just a side note, the perfect URL is /browser/someX/someY/pageNumberZ, so
/browser/someX/otherY?pageNumber=42 is already an attempt to balance effort and
result.
So, it would be nice if it was possible to write the
never-so-trivial-page-browser-form making good use of the wonderful
<stripes:param> and making the <stripes:form> GET instead of POST, and, tadam;
not showing any funky-looking hiddens (_sourcePage, __fp) in the query string.
> Make hidden fields (_sourcePage, __fb) optional for GET-forms
> -------------------------------------------------------------
>
> Key: STS-839
> URL: http://www.stripesframework.org/jira/browse/STS-839
> Project: Stripes
> Issue Type: Improvement
> Components: Tag Library
> Affects Versions: Release 1.5.6
> Reporter: Carl Krig
> Priority: Minor
> Labels: CleanURLs, form
>
> Use case; trivial page browsing form as part of a bigger screen
> ...
> Page
> <stripes:form action="/browser" method="get" style="display: inline;">
> <stripes:param name="some" />
> <stripes:param name="other" />
> <stripes:text name="pageNumber" onkeypress="javascript:if
> (window.event.keycode == 13 || event.which) this.parent.submit();">
> </stripes:form>
> of ${actionBean.pageCount}
> ...
> Problems;
> * GET puts the two hidden fields _sourcePage, __fb in the face of the user
> for no practical purpose
> * POST has the known refresh-side-effect (pressing F5 gives the user the
> popup asking permission to re-post)
> * The url is baked (has a @UrlBinding) so the stripes:param tags are really
> valuable to avoid hard-coding the recipe in multiple places, so substituting
> with a plain <form> tag is out of the question.
> Wish;
> It would be nice to have something like partial="true" that omits the hidden
> fields but still outputs the form tag.
> Suggestion 1: Add plain="true" with suggested functionality (Drawback:
> stacking yet another attribute on there)
> Suggestion 2: Make method="get" omit the hidden fields. (Drawback: might
> break existing code out there)
> Suggestion 3: Make method="get-funky" omit the hidden fields and output
> method="get". (Drawback: non-standard)
> Workaround is to go with the default method POST and add to the action code;
> if ("POST".equals(getContext().getRequest().getMethod())) {
> return new RedirectResolution(getClass()).addParameter("some",
> some).addParameter("other", other).addParameter("pageNumber", pageNumber);
> }
> Drawback with this workaround is of course the extra roundtrip just to hide
> nonsense query parameters.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
