On 11 Oct 2006, at 20:21, Martijn Dashorst wrote:
Yep, this is something we all are trying to achieve... The same old
purty framework, but with additional options to service the needy
greedy :-)
Phew.
I could envision an IEncodableModel interface:
interface IEncodableModel {
PageParameters encodeState();
void decodeState(PageParameters parameters);
}
That sounds fantastic. I guess a similar interface could be used by
the component to externalise its intrinsic state (visble/invisible
etc)? How would the component hierarchy itself be reconstructed?
On 11 Oct 2006, at 20:34, Eelco Hillenius wrote:
Hmmm. Yeah, that's an interesting choice to make. Is it the
responsiblity of models, or components. There is some logic to using
models, but I'm afraid things get really messy quickly then.
Components are the entity which know whether they are stateless or
not, and I think it is components that you would design specifically
for this purpose, not models. And however important models are in the
total scope of developing Wicket applications, they are subject to
components, which may - and often do - decide not to use models or
just partially (like the pageable list which uses a normal member for
the current page number).
I'm not really clear how responsibility /can/ be delegated to the
components? Would they just serialize the model into the URL? Can't
help thinking this would lead to some seriously long URLs, even for
detachable models (class name has to be in there, for a start).
Sorry if I'm asking stupid questions, but I'm trying to get up to
speed with the internals -- if I'm taking up too much of you guys
time, please do tell me to belt up, and I'll just watch instead!
P.
