Hi Serban, Feel free to create a patch with your proposed changes (IParams) and we will consider it. About stateless - see https://github.com/martin-g/wicket-stateless and https://github.com/robmcguinness/wicket-stateless <https://github.com/robmcguinness/wicket-stateless>Those are Jolira's ported to 1.5.
To work they need a patch in o.a.wicket.Behaviors.java which looks like: --- wicket-core/src/main/java/org/apache/wicket/Behaviors.java (revision 1091311) +++ wicket-core/src/main/java/org/apache/wicket/Behaviors.java (working copy) @@ -56,6 +56,7 @@ } internalAdd(behavior); + getBehaviorId(behavior); but it breaks few test expectations and I haven't had time to see whether this is harmful somehow. On Tue, Apr 12, 2011 at 10:51 AM, Serban Balamaci <[email protected]>wrote: > Hello Pedro, > In my mind IRequestParameters and PageParameters should have stemmed from a > common interface, extend some even generic one like(IKeyValues, IParams) > but > I trust you guys see the bigger picture maybe IRequestParameters is a very > generic thing that doesn't have to mean a page's parameters. > > By > "IRequestParameters interface has PageParameters correspondent API to > access > page parameters. Can be accessed like: > RequestCycle.get().getRequest().getQueryParameters()" you mean that > IRequestParameters has methods present in PageParameters? (yes I know, that > why I thought the methods could have been shared in a common interface). > > "If you want to recreate page parameters for some request, you can use the > PageParametersEncoder". It seems that PageParametersEncoder handles how the > parameters are rendered in the url(declared somehow like mounting pages) > and > I guess it does not have access to the original page parameters. And not > all > the parameters must be cloned, some must get overwritten and reflect the > new > state of the page. > > What I had in the original code is that I would have a helper method: > public static PageParameters keepPageParameters(PageParameters pageParams, > String[] paramNamesToKeep) { > // iterate through pageParams and recreate those with matching names > } > > and pass these parameters to bookmarkablepagelinks. I would use this method > from PageParameters coming both from super(PageParameters) and > RequestCycle.get().getPageParameters(). > > Now I must have two methods one that handles PageParameters and one that > handles , actually I have just one method now > public static PageParameters keepRequestPageParameters(IRequestParameters > pageParams, String[] paramNamesToKeep) and always get my parameters from > RequestCycle.get().getRequest().getQueryParameters() not from > > but it would have been better in my opinion to have a > public static PageParameters keepPageParameters(IParams pageParams, > String[] > paramNamesToKeep) { > } > > Btw does someone have a better way of keeping page parameters from one page > to another. I like the utility method that I see in the page I'm working on > what parameters I'm working with. > > I have not looked upon the new request cycle, I plan to, as migration to > 1.5 > is triggered by the feeling that somehow stateless ajax behaviours would be > easier to implement in 1.5. My current approach to was to have zero > compile > errors and then understand what is changed internally. > > Regards > > > ----- > http://balamaci.wordpress.com > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Wicket-1-5-PageParameters-vs-IRequestParameters-question-tp3442239p3444058.html > Sent from the Users forum mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com <http://jweekend.com/>
