i added a bunch of comments in the gist. not sure why we couldnt just do it here in place....
-igor On Thu, Aug 22, 2013 at 9:24 AM, Ben Tilford <bentilf...@gmail.com> wrote: > 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. > > >
