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
