On Aug 23, bernard01 commented (https://gist.github.com/dashorst/6308833/#comment-892525): > I find it very clean and extremely easy to deal with > PageParameters.
I disagree. I find PageParameters a cumbersome and leaky abstraction. I find it tedious to have to handcraft the parameters each time, having to convert the values by hand, having to scour through numerous lines of obfuscated code to see which parameters are necessary to construct a link or render a bookmarkable redirect. > They allow developers to instantiate pages with completely > different sets of parameters. Not sure what you mean by that. AFAIK this RFC doesn't limit the flexibility. > To formalise the conversion between PageParameters and sets of > values (not just IModel) one can use two-way converters within the > target page. That achieves 100% type safety: > > setResponsPage(MyPage.class, MyPage.createParameters(parameter1, > parameter2) This doesn't provide any more type safety than the RFC proposes. It's a nice convention, but that's it. > The proposed solution must show how to achieve type safety. See sections 4.4 and 8.1 in the RFC for an example that utilizes bean parameters to achieve type safety in a clean way without having to rely on ad-hoc naming or types. It is my opinion that using bean parameters as defined in the RFC provides the best type-safety we can possibly achieve in Java, and in a better, more formal way than using PageParameters. > varargs or builder that add arbitrary parameters cannot be used to > provide type safety (which comes with code completion in IDEs). > Here is why: Wrap a parameter builder in a type safe converter. The > parameter builder or varargs object - what are they? Just another > way to represent name value pairs - which is what PageParameters > are - except they are broken because the names are missing. > So one cannot build the type safety even with a converter. > The annotation approach is good for web services where the > consumer is outside the system, and a complete tool chain exists to > generate the annotations and wsdl which provides the type safety at > the other end. I don't understand what you mean here. There is no generation of code necessary. Annotations can be used for more than just code generation. Please read some JAX-RS examples to see what we are trying to accomplish if you want to learn about our vision. I can specifically recommend reading section 3.2 of the Jersey documentation: http://jersey.java.net/documentation/latest/jaxrs-resources.html#d0e1433 (I hope the link keeps working). > Do we want to provide this? No. There is no need for code generation. > Perhaps behind the annotations should be be real classes that > provide the type safety. Again I don't understand what you mean here. > Something like jsr303 bean validation. I would like to integrate JSR-303 bean validation into the proposed mechanism, but I think we should first tackle this issue before piling on extra specifications. > This is a generic problem of two-way mapping between name-value > pairs and and arbitrary objects. Why is Wicket trying to solve > this? Because Wicket needs to parse and schedule incoming requests, which requires a tight integration into the Wicket core. However, we are modeling our RFC after a Java standard: JAX-RS. We intend to follow that standard as close as possible and as long as it make sense in Wicket. But we need to ensure that our needs are served well, and that we won't conflict with other technologies using nearly the same names. For example I'd rather use different packages and different names for the annotations than JAX-RS uses to avoid classpath conflicts. > Given the maturity of the Java ecosystem and the basic nature > of the problem I would guess that either 1) we can use an existing > solution and plug it in or 2) this problem does not have a generic > solution. I would consider looking at ASL licensed frameworks for their parameter parsing and injection code. Rest-Easy comes to mind as one library that could be used. That said, I would at least ensure that we don't introduce issues with our framework for users that use RestEasy or Jersey or any other JAX-RS implementation. But it is too early to discuss this implementation detail. > I guess it is 2) because of validation constraints. I'm not sure what you mean by this. > I would prefer if Wicket keeps PageParameters and provides > PageParameter converters to support type safety. Developers just > code them anyway so we are not asking for them. They would be great > for beginners though. Let's see what the RFC looks like when its finished and if PageParameters are still necessary. I try to design the RFC such that PageParameters will be obsolete, and as a result for them to go away, Martijn
