Martin Grigorov commented:
https://gist.github.com/dashorst/6308833/#comment-892137
> > 7.1.3 setResponsePage(Class<?>, PageParameters) removed
>
> What will be the new way to make a redirect with path and/or query parameters
> ?
It says TODO in the RFC for a reason.
I'm inclined to propose something like:
setResponsePage(EmployeePage.class, companyId, employeeNr, managerNr);
However this seems naive for several reasons:
- how can we distinguish between Long, Long and Long? Is the order
of arguments relevant? The binding of parameters should follow a
strict rule, something like:
- first the constructor arguments are processed in order
- next the fields are processed in order
- if the type of a parameter is not assignable to the
constructor argument/field at the specified location, throw an
error (IllegalArgumentException)
Unfortunately this doesn't solve the problem that one has to look
up the order of parameters in the Page class and interpret them
yourself in the right order. It is however something we can spec
out, to ensure there is no doubt as to which parameter goes where.
- it misses out on the name-value binding, but that really does suck
in Java anyways (no named parameters). I have no idea if it would
solve a real problem when we introduce a name-value binding for
setResponsePage(...)
- Working with optional parameters makes it even more involved
- Working with free form parameters is also an unsolved issue
Another option would be to make setResponsePage() a builder,
something like:
redirectToPage(EmployeePage.class)
.with(companyId)
.with(employeeNr)
.with(managerNr)
.with("foo", "bar")
.go();
Again, this is just a thought experiment for this particular issue
and I have not thought about the URL generation part yet.
Martijn
