I see that 1.1.3 How Other Web Technologies Work
explains how type safety can work with a single complex parameters container @BeanParam. @BeanParam functions both as the converter that I have been referring to and as a PageParameters replacement. My concern is multiple parameters where the use of builder and varargs was proposed in the discussion for good reasons, and they have been shown to be unsafe. How do you want to pass multiple simple parameters safely with setResponsPage() without an enclosing container? 7.1.3 setResponsePage(Class<?>, PageParameters) removed TODO 7.1.4 BookmarkablePageLink(Class<?>, PageParameters) removed TODO, also see 8.1 for a discussion. As the RFC stands, to be type safe, the system would have to be limited to the use of @BeanParam, not supporting multiple parameters as described in 2.3 and 4.2. @BeanParam, @PathParam and @QueryParam might have to share the same interface so that they can be passed around and used in 7.1.3 and 7.1.4 I wouldn't have a problem with using @BeanParam exclusively as a replacement for PageParameters. With PageParameters, even if there is only one parameter, one always needs the PageParameters object anyway, so let's get over it. A page could have three constructors: 1) No-args (should be called if no parameters for the page exist. This is currently broken - Wicket does not call it anymore) 2) BeanParam (should NOT be called with an empty BeanParam!!!!) 3) IModel Bernard On Fri, 6 Sep 2013 22:24:09 +0200, you wrote: >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
