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).
It would work like I started my email with.
It is not my intention to serialize all state of the components/
models. This is the 'brute force' approach of JSF and .NET (yes I know
somewhere down the line it is probably somehow configurable :) ).
Stateless components currently just don't keep any state you put in
them. Much like .NET or Tapestry where you can put all the variables
you want in the pages, but the page will be recreated on each call.
State you want to transfer must be put in ViewState (.NET), or
configured/ annotated (Tapestry). This optional state thingy is
something I'm proposing here for Wicket.
Eelco
