Apache Wicket is an open source Java component oriented web application framework. This document specifies modernization to the way Wicket handles PageParameters in the processing of requests and the lifecycle of Page components, based on the specifications done for JAX-RS (JSR-311 and JSR-339).

wicket-rfc-0001.txt

Please see https://github.com/dashorst/wicket-rfcs/blob/master/wicket-rfc-0001.txt for the RFC.

Please comment either inline in the github repository, or reply to the message 
thread on the [email protected] mailing list.

Hi everybody!

I have to finish yet to read the complete rfc document. I agree that sometimes PageParameters can generate a little bit of confusion when we use them with page constructor or links. I also agree that the code for mounting pages/resources should be more neat and clear (too many IRequestMapper ??).
However I don't understand why we should get rid (or heavily modify) PageParameters. The funny thing (of course for me) is that PageParameters have been very helpful writing REST module for Wicket, which basically offers the same features (and the same approach) of JAX-RS.
REST module for Wicket: https://github.com/wicketstuff/core/tree/master/jdk-1.6-parent/wicketstuff-restannotations-parent

I find it very clean and extremely easy to deal with PageParameters. They allow developers to instantiate pages with completely different sets of parameters. 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)

The proposed solution must show how to achieve type safety.

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. Do we want to provide this?

Perhaps behind the annotations should be be real classes that provide the type safety . Something like jsr303 bean validation.

This is a generic problem of two-way mapping between name-value pairs and and arbitrary objects. Why is Wicket trying to solve this? 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 guess it is 2) because of validation constraints.

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.