Triggered by that question earlier this week about how to externalize
the urls of a pageable list, I thought a little bit about
externalizing state by components.
I think with Wicket 2.0, we got a bit closer to being able to do that,
as we can traverse the whole hierarchy after creation.
RequestCycle#urlFor (or any of the delegates) could for instance
traverse all components, and look for an annotation like this:
public class SomePagingComponent extends Blah {
...
@UrlEncoded private transient int pageNbr = 1;
}
Which would work with to string by default, and additionally,
components could implement an interface to customize this:
public interface ParameterUrlEncoder {
CharSequence encode(String propertyName);
void decode(String propertyName, String encodedValue);
}
The mechanism (somewhere in urlFor calls) could take care of the
proper naming/scoping of variables, and could compress (and later
decompress) the total contributed part of the URL. The request
resolving part of the request cycle handling, should then inject the
state again.
Maybe (probably) I'm overlooking something, but I think this is
feasible and actually not that hard to achieve. I think it would be
VERY nice to have this, not only for bookmarkability without having
having to give up on component scoped programming model, but also for
scalability, where you can decide to use stateless pages with
components like this (which could in many cases be stateless too).
The main problem we would have is what to do with URLs that exceed the
max lenght (which btw does not seems to fixed on 255 as I always
thought, though 255 is recommended as a safe - but maybe outdated -
upper limit, but I have seen 2048 and higher mentioned as well). The
obvious thing to do is - like .NET and JSF - convert all gets to
POSTs, but that gets really messy to implement (though due to our
redirecting for renderings, users shouldn't notice).
WDYT, anyone wants to give this a go?
Eelco
