By deprecate I hope you don't mean remove. This change would break almost every single wicket application ever written.
On Thu, Aug 22, 2013 at 9:55 AM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: > In the previous thread where I spin this message from it was mentioned by > Emond that he and I were discussing request parameters and how Wicket > handles them. > > It occurred to me that the PageParameters construct is still with us from > 2004 and that it hasn't changed much since. In fact I'd posit that > PageParameters are confusing and archaic when compared to more modern web > technologies, e.g. jax-rs. > > So we started to write an RFC for Wicket, trying to document exactly what > we want to change and how it should behave. It is quite a work in progress, > but I like the first baby steps. > > There is not a good platform to host the rfc text (I loathe the confluence > editor and markup), so I put it in a gist at github, as a place to read it, > comment on it, and suggest improvements. > > You can find the first–incomplete as in not written yet–cut of Wicket > RFC-0001 here [1] > > It is my intention to see if we can get consensus on this subject, and > start implementing it in wicket 7. > > If we were to implement this, it would mean at least the following API > breaks: > > 1. Remove Page#PageParameters constructor > 2. Remove PageParameters storage from Page > 3. Remove Page#getPageParameters() > 4. Remove PageParameters > > In turn we would get type safe parameters for pages, a clear semantic how > request parameters relate to the life cycle of pages and components and > annotation based declaration of mount paths for pages. > > I at least like the provided examples, though we haven't touched the > difficult subjects yet, such as URL generation, keeping them sync'd when > doing partial page refreshes (read: AJAX), etc. > > Martijn > > [1] https://gist.github.com/dashorst/6308833#file-wicket-rfc-0001-txt > > PS. I like the RFC format quite a bit as it allows me to explore the intent > and consequences before implementing a change. The examples make it more > concrete to my taste and if this one is successful (i.e. either we accept > the RFC or we don't accept the RFC based on the contents) I'd like to see > more of them. > > PS2. anyone with an interest is invited to help out with the details and > the grander picture. You don't need commit bits to help out with this > subject. >
