About changing parameters on stateful pages, one comment: one thing that makes Wicket secure by default is exactly the fact that you get the parameters when you create a page, and everything after is made by interacting with components (which don't process values if disabled, invisible, or invalid). If changing the URL now will re-inject parameters on already-created stateful pages, it could lead to lots of security issues.
What the original author of the issue 4441 wanted, as I understand it, is an easy way to get path parameters of the current request (query and post parameters are already available), which is perfectly fine since you have to ask for it, not to automatically change the PageParameter object of the page. About the setResponsePage() issue, I agree that varargs is not a good solution at all. The builder is better, but is not better than just using a PageParameter object. Keeping parameters separated from the base URL gives you the flexibility of reusing a set or parameters to navigate to various pages. With the builder, since the target page is the root, you'd have to execute code to add each parameter to the builder, instead of reusing a pre-built instance. And, if you add a 'with(parameters)' method, what's the difference of just using a PageParameter in the first place? And one more use-case: if I want a page to receive not a fixed set of parameters, but any parameter that comes from the request? Say, an intermediary page that must redirect (or forward) to another after some processing, without having to URL-encode the whole redirect URL beforehand, or that must accept POST requests. One could, of course, get the request object and read the parameters directly from it, but would lose the niceties of PageParameters, like conversion and default values. Is it a too edge-case scenario? On Fri, Aug 23, 2013 at 10:40 AM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: > On Fri, Aug 23, 2013 at 3:28 PM, Martin Grigorov <mgrigo...@apache.org> > wrote: > >> I'd like to extend to pages as well: have stateful pages be able to > >> respond to updated request parameters. > > > > See https://issues.apache.org/jira/browse/WICKET-4441 > > I know of 3 users complained with this problem. Don't ask me to dig the > > mails. Just FYI. > > Yup, this is what triggered the RFC in the first place, when we > started looking at how we would like to see how page parameters should > work. Having done largish projects with JAX-RS, we feel that that > programming model is a vast improvement over the current > implementation in Wicket. > > It is something I'd like to spec to death in the RFC on how to work > with existing stateful pages and parameter injection. > > Martijn >
