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
