ahh now your are making sense to me because this above:
No this externalizable thing only means that 'state' is being passed as part of the URL. So an URL like this http://localhost:8081/tsp/web?wicket:interface=_wf_component:1:10:1: could be something like http://localhost:8081/tsp/web?wicket:interface=_wf_component:1:10:1:&wicket:state=dfskajkladsjf676sdfa didn't make any sense to me. Because that will be a statefull component what ever the cost so that wicket state after a wicket:interface only thing is completely redundant because that state will be there no matter what. Or are you saying that we are detaching (setting all the fields to null) where we make the state from? stateless components have both so something like this: http://localhost:8081/tsp/web/my/mout<http://localhost:8081/tsp/web?wicket:interface=_wf_component:1:10:1:&wicket:state=dfskajkladsjf676sdfa> ?wicket:interface=_wf_component:1:10:1:<http://localhost:8081/tsp/web?wicket:interface=_wf_component:1:10:1:&wicket:state=dfskajkladsjf676sdfa> or http://localhost:8081/tsp/web<http://localhost:8081/tsp/web?wicket:interface=_wf_component:1:10:1:&wicket:state=dfskajkladsjf676sdfa> ?wicket:bookmarkablePage=xxxxx&wicket:interface=_wf_component:1:10:1:<http://localhost:8081/tsp/web?wicket:interface=_wf_component:1:10:1:&wicket:state=dfskajkladsjf676sdfa> after these urls we could push the wicket:state and if we then can't connect to the wicket:interface part but only to the bookmarkable part we can push the state back in again. johan On 10/11/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
I'd like to chip in here to state that by what I proposed I don't want to make Wicket suddenly a stateless framework or something. I'm primarily looking for scalability optimizations. We made a step in the right direction with stateless pages/ forms/ links, but the next step nice step on top of this is to be able to make these stateless components partially statefull again by declaring the fields that should be externalized. If we keep it simple - never try to magically transform to posts - I think it's doable and even quite elegant. It would actually give us a Tapestry-like programming model, but then with Wicket's flexibility and the option of mixing the programming models. As an extra, combined with URL mounting, it would be a bit easier to create pages with nice URLs, because rather than having to fall back on coding to the page level people have to do now, people could use bookmarkable pages and components to push out state to keep the scope and state on a component level, while still achieving bookmarkability. I think it's worth to take a look, and honestly, I don't even think it'll be that difficult for Wicket 2.0 Eelco
