I haven't had time to read the proposal in its entirety yet, so I just skimmed it. My first impression is pretty good. There are of course some things still missing, such as programmatically changing page parameters to update the displayed URL in the browser, and centralized mounting.
I'm not sure this fixes a major problem, but it would certainly be nice to not have to do manual string conversions anymore as we are currently doing with PageParameters. On the other hand, I'm not a big fan of sprinkling annotations everywhere. It feels like that usually only fixes the easy cases - of course, the easy cases are fixed very nicely that way. I'm struggling to come up with a scenario that wouldn't be covered by this, but for now I just have this nagging feeling that there should still be a programmatic way to extract parameters, not just the annotation based stuff. I'll be back with more comments after the weekend, I hope. On Thu, 22 Aug 2013 17:55:45 +0200 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.
