On Thu, Aug 22, 2013 at 11:08 AM, Emond Papegaaij < [email protected]> wrote:
> On Thursday 22 August 2013 10:43:57 Martin Grigorov wrote: > > On Wed, Aug 21, 2013 at 10:10 PM, Emond Papegaaij > <[email protected] > > > wrote: > > > For Wicket 7, we might want to take a look at the PageParameters and > > > mounts > > > because they hold several caveats. The most important is that the > > > lifecycle > > > of PageParameters if different than that of the Page they belong to. > > > PageParameters are bound to a request, whereas a page instance > can live > > > for > > > many requests. Also, it is possible to modify the PageParameters > passed to > > > > PageParameters has a confusing name, e.g. PageParameters are > passed to > > IResource#respond(Attributes#getPageParameters). > > Here is how I understand the lifecycle - when a page is instantiated > Wicket > > may pass PageParameters to its constructor. Those PageParameters > have the > > same lifecycle as the page itself. They are reachable via > > Page#getPageParameters. > > When a link is clicked its parameters are reachable in #onClick via > > getRequest.getRequestParameters. Using getPage.getPageParameters > will > > return the parameters for the page creation, not for the link's click, or > > form submit. > > The mismatch is in the fact that the PageParameters object is stored with > the page while it resembles the parameters the page was created with. If > a page changes (for example, by updating its model object), the > PageParameters no longer match with the state of the page. That's why I'd > rather not store them in the page at all but recreate them when needed. > I don't see why Page's parameters should be related 1:1 to page's model. The parameters are just the data that has been provided for the page construction. Nothing more. Later they could be used for url generation or not. The page may use some of the parameters to create its model or not. > > > the super contructor, but those changes will be overridden by Wicket > after > > > > I don't see what you mean here. > > DefaultPageFactory:204 If you change the PageParameter instance in the > construtor, wicket will overwrite it. > > > > constructing the page. Finally, you can override getPageParameters in > your > > > > Yes. Overriding this method may return wrong data later. > > See > > > https://cwiki.apache.org/confluence/display/WICKET/Wicket+7.0+Roadmap# > Wicket > > 7.0Roadmap-PageParametersimprovements - > > here I suggest to make the Page's parameters immutable. I like this > change > > A LOT, but as you can see in the patch in > > https://issues.apache.org/jira/browse/WICKET-4774 it requires too many > API > > breaks :-/ > > If we do not store the PageParamters in the page anymore, there will be no > need for a mutable PageParameters object. Still, the API break will be > huge. > > > > page, which will confuse Wicket even more. Also, PageParameters only > > > handle > > > strings, which is quite limited. I don't know how to improve this. > Perhaps > > > > What do you mean by this ? The data coming from the client is not typed, > so > > using String is the most natural choice. You can use StringValue#toXyz() > to > > convert it to other primitives. > > JAX-RS is able to convert any object from and to Strings using some well > known patterns: A constructor taking a string or a static valueOf(String) > method. > > Best regards, > Emond >
