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. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 handling in components...which would be horrific. -igor I need to bring this topic up once more. My current solution is to do the background processing in a separate thread and install a timer on the page to poll until the panel's content is ready. The resulting code is ok but feels heavy and unnatural. I would prefer a simpler solution. (I could not use iframes because they CSS does not have enough control over them.) If I understand correctly, several pages can load asynchronously because only the state within a page is protected with synchronization. If so, can't one introduce a stateless component that lives in its own dummy page? I have the hope that if this is done nicely and the dummy page is abstracted away, it would feel much more natural to code asynchronous loading. For example, such a LazyComponent would be constructed with the name of a wicket fragment. When rendered, it displays whatever markup has been add()'ed to the component (loading). When rendered, it makes an AJAX request to load the wicket fragment, which under the hood sits in a dummy page. I don't know enough about Wicket right now to code this so I want to ask whether this is possible and if yes, how this idea can be improved and whether somebody would be available with a few pointers to get me started. Thanks, Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 for component subtrees. then multiple ajax updates of different screen areas could happen simultaneously. i believe this could be implemented fairly easily with a Component.getLock() method that chains up the hierarchy looking for locks. the default page lock would be at the top and subtrees that got locked by ajax updates would add new lock objects via Component metadata. of course the page lock would have to be used to add that metadata to prevent a race condition, but it seems like it would work. then again, i'm not intimately familiar with our ajax implementation these days. Kaspar Fischer-2 wrote: I am trying to find out how to load several parts (Wicket panels) of a page in parallel using Ajax. The content of these parts takes long to render but I still want the user to see the other, readily available parts of the page, with the delayed panels appearing when available. Several posts on this list indicate that AjaxLazyLoadPanel's only work synchronously. Is this still the case with the latest version/snapshot of Wicket? Is there maybe another approach available (one that still uses Wicket for the parts)? Thanks, Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://old.nabble.com/Asynchronous-construction-of-page-tp26171123p27018131.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 becomes not so easy to figure out which component should actually own the root lock. -igor On Mon, Jan 4, 2010 at 11:37 AM, Jonathan Locke jonathan.lo...@gmail.com wrote: 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 for component subtrees. then multiple ajax updates of different screen areas could happen simultaneously. i believe this could be implemented fairly easily with a Component.getLock() method that chains up the hierarchy looking for locks. the default page lock would be at the top and subtrees that got locked by ajax updates would add new lock objects via Component metadata. of course the page lock would have to be used to add that metadata to prevent a race condition, but it seems like it would work. then again, i'm not intimately familiar with our ajax implementation these days. Kaspar Fischer-2 wrote: I am trying to find out how to load several parts (Wicket panels) of a page in parallel using Ajax. The content of these parts takes long to render but I still want the user to see the other, readily available parts of the page, with the delayed panels appearing when available. Several posts on this list indicate that AjaxLazyLoadPanel's only work synchronously. Is this still the case with the latest version/snapshot of Wicket? Is there maybe another approach available (one that still uses Wicket for the parts)? Thanks, Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://old.nabble.com/Asynchronous-construction-of-page-tp26171123p27018131.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 invalid to have a fine-grained lock on a subtree with a model being accessed by components outside that subtree. i'm not saying this is a great idea, just trying to clarify this thinking-out-loud idea... igor.vaynberg wrote: 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 becomes not so easy to figure out which component should actually own the root lock. -igor On Mon, Jan 4, 2010 at 11:37 AM, Jonathan Locke jonathan.lo...@gmail.com wrote: 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 for component subtrees. then multiple ajax updates of different screen areas could happen simultaneously. i believe this could be implemented fairly easily with a Component.getLock() method that chains up the hierarchy looking for locks. the default page lock would be at the top and subtrees that got locked by ajax updates would add new lock objects via Component metadata. of course the page lock would have to be used to add that metadata to prevent a race condition, but it seems like it would work. then again, i'm not intimately familiar with our ajax implementation these days. Kaspar Fischer-2 wrote: I am trying to find out how to load several parts (Wicket panels) of a page in parallel using Ajax. The content of these parts takes long to render but I still want the user to see the other, readily available parts of the page, with the delayed panels appearing when available. Several posts on this list indicate that AjaxLazyLoadPanel's only work synchronously. Is this still the case with the latest version/snapshot of Wicket? Is there maybe another approach available (one that still uses Wicket for the parts)? Thanks, Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://old.nabble.com/Asynchronous-construction-of-page-tp26171123p27018131.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://old.nabble.com/Asynchronous-construction-of-page-tp26171123p27019945.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 lazy panels takes time, the user experiences slow response in the auto-completion field. Please correct me if I am wrong. Kaspar On 06.11.2009, at 08:47, Pieter Degraeuwe wrote: 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 kaspar.fisc...@dreizak.com wrote: 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 lazy panels takes time, the user experiences slow response in the auto-completion field. Please correct me if I am wrong. Kaspar On 06.11.2009, at 08:47, Pieter Degraeuwe wrote: 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Asynchronous construction of page
That's what I ended up doing (basically like http://blog.miau.biz/2008/12/wicket-and-slow-running-process-in.html). 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 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 kaspar.fisc...@dreizak.com wrote: 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 lazy panels takes time, the user experiences slow response in the auto-completion field. Please correct me if I am wrong. Kaspar On 06.11.2009, at 08:47, Pieter Degraeuwe wrote: 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 kaspar.fisc...@dreizak.comwrote: On 05.11.2009, at 03:06, jpswain wrote: 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? I am very happy with Wicket's speed but sometimes the data that needs to be displayed by Wicket is not readily available. In my application, I need to do display the results of several calculations, each of which may require a different amount of time. Unfortunately, there is not a lot to cache. -- I want to display to the user a page right away and as the results come in, in whatever order, show them. Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pieter Degraeuwe Systemworks bvba Belgiëlaan 61 9070 Destelbergen GSM: +32 (0)485/68.60.85 Email: pieter.degrae...@systemworks.be visit us at http://www.systemworks.be
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 Wicket without having to spawn a thread from the HTTP request itself. Nonetheless, here's a blog post on handling requests in separate threads: http://blog.miau.biz/2008/12/wicket-and-slow-running-process-in.html Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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.(...) and if the buildPanel1 thread implementation write to response the component html on it finish? Only a very crude idea... can it work? On Wed, Nov 4, 2009 at 4:09 PM, Kaspar Fischer kaspar.fisc...@dreizak.comwrote: 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 Wicket without having to spawn a thread from the HTTP request itself. Nonetheless, here's a blog post on handling requests in separate threads: http://blog.miau.biz/2008/12/wicket-and-slow-running-process-in.html Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pedro Henrique Oliveira dos Santos
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 parallel using Ajax. The content of these parts takes long to render but I still want the user to see the other, readily available parts of the page, with the delayed panels appearing when available. Several posts on this list indicate that AjaxLazyLoadPanel's only work synchronously. Is this still the case with the latest version/snapshot of Wicket? Is there maybe another approach available (one that still uses Wicket for the parts)? Thanks, Kaspar -- View this message in context: http://old.nabble.com/Asynchronous-construction-of-page-tp26171123p26208074.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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, otherwise you would have to do your own multithreaded access handling in components...which would be horrific. -igor On Mon, Nov 2, 2009 at 1:32 PM, Kaspar Fischer kaspar.fisc...@dreizak.com wrote: I am trying to find out how to load several parts (Wicket panels) of a page in parallel using Ajax. The content of these parts takes long to render but I still want the user to see the other, readily available parts of the page, with the delayed panels appearing when available. Several posts on this list indicate that AjaxLazyLoadPanel's only work synchronously. Is this still the case with the latest version/snapshot of Wicket? Is there maybe another approach available (one that still uses Wicket for the parts)? Thanks, Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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, Nov 2, 2009 at 1:32 PM, Kaspar Fischer kaspar.fisc...@dreizak.com wrote: I am trying to find out how to load several parts (Wicket panels) of a page in parallel using Ajax. The content of these parts takes long to render but I still want the user to see the other, readily available parts of the page, with the delayed panels appearing when available. Several posts on this list indicate that AjaxLazyLoadPanel's only work synchronously. Is this still the case with the latest version/snapshot of Wicket? Is there maybe another approach available (one that still uses Wicket for the parts)? Thanks, Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
