Re: Asynchronous construction of page

any progress w.r.t. to this question? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Asynchronous-construction-of-page-tp1892224p2270690.html Sent from the Wicket - User mailing list archive at Nabble.com.

Re: Asynchronous construction of page

true, but i think the component tree would be locked, not the models. and just to play devil's advocate... such a feature could be off by default and in development mode it could do a complete check of the tree for root model objects being used outside the locked subtree... such that it would be

Re: Asynchronous construction of page

this is still highly error prone. locking a component subtree is not always enough. usually component subtrees share a model object that is somewhere higher up, so it is the component that owns the root model object that needs to be locked. but, once you throw in model chaining into the mix it beco

Re: Asynchronous construction of page

i know i'm jumping into this in the middle and maybe someone already proposed this or it's not a good idea for some reason that's not immediately obvious, but i wonder if we could do some lock splitting here (in wicket 1.5?) so that the coarse grained page lock is replaced with a locking system f

Re: Asynchronous construction of page

On 02.11.2009, at 22:59, Igor Vaynberg wrote: > if you want nonblocking you have to make each thing you are trying to > load asynchronously its own page inside an iframe. > > the page itself can only be accessed synchronously, otherwise you > would have to do your own multithreaded access handli

Re: Asynchronous construction of page

That's what I ended up doing (basically like ). I just wanted to explain to Pieter why ... On 28.11.2009, at 11:27, Johan Compagner wrote: > load that data in separate threads, dont touch any wicket components > in those thre

Re: Asynchronous construction of page

load that data in separate threads, dont touch any wicket components in those threads make a component like ajaxlazyload that polls for that data if still not there use a timer of a few seconds to test it again On 28/11/2009, Kaspar Fischer wrote: > Because the requests will be sequential (a prob

Re: Asynchronous construction of page

Because the requests will be sequential (a problem in general but not so much in my case) and because I have an auto-completion field on the same page. As I understand it, having some AjaxLazyLoadPanel's active on my page, the auto-completion requests will be queued. So if the loading of the laz

Re: Asynchronous construction of page

Why don't you use the AjaxLazyLoadPanel for each part the the screen that takes some time to load? (see also at http://www.roseindia.net/tutorials/wicket/lazy-load.shtml) Pieter On Thu, Nov 5, 2009 at 6:00 PM, Kaspar Fischer wrote: > On 05.11.2009, at 03:06, jpswain wrote: > > Wicket is remark

Re: Asynchronous construction of page

Wicket is remarkably fast and efficient the way it is used in common practice. To do what you are suggesting would be to wreck that big time. Why on earth do you want to do this? Kaspar Fischer-2 wrote: > > I am trying to find out how to load several parts (Wicket panels) of a > page in par

Re: Asynchronous construction of page

One question: if component renderComponent method wasn't final if Kaspar page structure was -page - panel1 - paneln if page renderComponent method implementation was buildPanel1.start() buildPaneln.start() and renderClosingComponentTag implementation was allPanelReady.join() super.(...)

Re: Asynchronous construction of page

On 02.11.2009, at 22:59, Igor Vaynberg wrote: the page itself can only be accessed synchronously, otherwise you would have to do your own multithreaded access handling in components...which would be horrific. It's definitely not nice and it would be cool if there were some way to do this in

Re: Asynchronous construction of page

I will try to use pages in iframes then. Thanks a lot, Igor. Kaspar On 02.11.2009, at 22:59, Igor Vaynberg wrote: if you want nonblocking you have to make each thing you are trying to load asynchronously its own page inside an iframe. the page itself can only be accessed synchronously, otherwi

Re: Asynchronous construction of page

if you want nonblocking you have to make each thing you are trying to load asynchronously its own page inside an iframe. the page itself can only be accessed synchronously, otherwise you would have to do your own multithreaded access handling in components...which would be horrific. -igor On Mon