Hi, As I said in the gist comments my main concern is that this RFC doesn't solve a real problem. There are no issues with the PageParameters now. There are no complains in users@ about them...
But I also know that the volunteer work on Open Source projects is driven by interest - either company interest or personal one. So create a branch and have fun! When you are satisfied with the new functionality then we can vote to merge it in master. At the moment there are many unknowns both because we don't see the new functionality with your eyes and because you don't know all the details about PageParameters' usage in Wicket internals. In any case we will all learn something new and hopefully deliver a better solution for the Wicket users. On Fri, Aug 23, 2013 at 1:16 AM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: > On Thu, Aug 22, 2013 at 11:42 PM, Igor Vaynberg <igor.vaynb...@gmail.com> > wrote: > > On Thu, Aug 22, 2013 at 2:04 PM, Martijn Dashorst > > <martijn.dasho...@gmail.com> wrote: > >> > >> On Thu, Aug 22, 2013 at 10:09 PM, Ben Tilford <bentilf...@gmail.com> > wrote: > >> > >> > There really isn't a good reason to remove them even if parameter > injection > >> > is added. > >> > >> > >> Yes there is: > >> - removing maintenance burden > >> - removing confusion > >> - making the implementation of the new API feasible. > >> > >> Removing maintenance burden > >> > >> Instead of just having to maintain the new API, we have to maintain the > old > >> API in the same codebase, and ensure compatibility remains between the > two. > >> This may be harder than it seems from the outset. > > > > the pageparameter api hasnt really been a source of bugs or a > > maintenance headache. internally we will still need a datastructure to > > carry the parameters, might as well reuse whats there now. > > Unless what's there now is large and complex and no longer necessary. > The URL generation and mounting APIs have undergone at least one major > rewrite because they were cumbersome to maintain and a big source of > bugs. > > We also need to ensure that both the new API and the old API can work > together: that is (a lot) more work. > > > further, > > what will the api look like to generate bookmarkable urls? > > Not sure yet, the RFC is not ready yet. > > > still need > > pageparameters to carry those params forward in bookmarkablelink, etc. > > Not necessarily: the API is still under construction. It is the > intention to remove the need for PageParameters altogether in the API. > > >> Removing confusion > >> > >> Keeping both APIs means there exist multiple ways to achieve the same > thing > >> which is bad: what would happen if you use both PageParameters and the > new > >> API in the same class or constructor? > > > > i dont by this, same can be said for constructor vs field injection. > > I posit that this RFC is one way of achieving a goal and that the > current API is another and that these two are mutually exclusive: this > RFC is intended as a replacement for the current APIs, not as an > alternative. > > > what if they define some params in constructor and others in fields? > > This is readily specified by the JAX-RS specification which we can use > as our definition of how to work with these. Constructor and field > parameters in JAX-RS aren't mutually exclusive: all parameters are > populated regardless if they are constructor arguments or fields. > > Using field injection is useful when the list of possible parameters > is largish. Methods with more than 3 parameters are cumbersome to > read. Having field injection as an alternative is a welcome addition. > > One could use the path parameters (required) as constructor > parameters, and query parameters as optional field parameters. > > Martijn >
