Ronaldtm commented: https://gist.github.com/dashorst/6308833/#comment-891818 > What if you have many pages that receive the same parameters, and > those have to be converted to a TO?
For that one can use the @BeanParam, which I intend to model similar to the JAX-RS implementation. Basically it is a bean where you can specify the parameter annotations in a reusable way. > Or multiple-field objects (like, a Date could be created by three > inputs, '_year', '_month', and '_day', with some common prefix). > > With PageParameters, I could just have a static method that takes > PageParameter and returns the object, and reuse it in every page. Not > being allowed to do this would take a lot of control off our hands. While I don't have a solution yet, it is my intention to make sure we can address most cases, though not all. In this case I can envision a @BeanParam that takes the 3 fields from the request and has a getDate() method for further use. > And even if this new parameter system implemented something like > SpringMVC's annotated parameters (can take POJOs, inject parameters > into their properties, etc.), I think it would be very complex and > confusing (just like SpringMVC). I have no experience with SpringMVC, so I cannot claim that it is very complex and confusing. I do have experience with JAX-RS and I don't find it complex nor confusing. I do think that the current PageParameters make it very hard to understand what a page requires and all the hand written conversions to craft bookmarkable links make it hard for me to continue to advocate PageParameters continued existence. Note that the proposal is still in its infancy. It will get more meat and it will become more clear how to do things in the proposed new way. Also note that this is just a proposal. It is not set in stone, and it is not even certain it will be implementated. Martijn
