FYI I've worked out a very simple / no frills way to do this. <t:parallel> <t:someComponent /> </t:parallel>
The parallel component would then render it's ComponentResources.getBody() in a separate thread (note that the body Block can be TypeCoerced to RenderCommand). As Thiago discussed, his shell element concept could be achieved by passing an empty RenderQueue and MarkupWriter to the body RenderCommand (which is rendering asynchronously to the main request). Once the async render finishes, the resultant markup String could be introduced into the main DOM on the request thread. Note that request / response will be null on the async thread. Any request scoped property bindings and Environmentals will also be null. PerthreadManager.cleanupThread() should be called after the async render. On 5 Nov 2014 16:51, "Thiago H de Paula Figueiredo" <thiag...@gmail.com> wrote: > Hello, Alex! > > On Tue, 04 Nov 2014 21:23:10 -0200, Alex Kotchnev <akoch...@gmail.com> > wrote: > > I'm a bit puzzled by the negative vibe that I'm getting. Just to be clear >> - >> > > I'm not perceiving any negative vibe, just one idea being proposed and > some people thinking that it wouldn't actually reach its objective (making > page rendering faster). > > I'm not asking anyone to do any work on my behalf, or to drop everything >> and work on this as if it's the most important thing in the world (which >> it is not). I'm also not here to troll and say "tapestry sucks, this other >> framework is better" >> > > I don't think anyone here is thinking that. I definitely am not. :) > > - nothing of the sort (in my first email I did > >> explicitly mention that after evaluating the two for a while I did find >> Tapestry to be superior and I'm still sticking with it). I saw this >> approach in a different framework, I found it interesting and I'm curious >> for input from the more knowledgeable people on this list on how one >> might tackle this. >> > > I actually think it's doable without a thread-safe DOM, but with some > limitations, even if I think it's not worth the effort: > 1) The component would need to generate a DOM element immediately, let's > call it shell element, before spawning a new thread. This way, the new > thread would only work inside this shell element, avoiding the need of > synchronizing the whole DOM tree (Document instance). This could be > implemented with a new render phase event. > 2) The component should avoid changing DOM elements it didn't create > (a.k.a DOM rewriting), just creating new elements inside this shell element. > 3) The component couldn't be in a loop (Loop or Grid), as the same > component instance is rendered many times. > 4) The developer must know that things may go wrong in unexpected ways. > > likely be much faster than actually getting the data. The trouble is that >> I did try the approach of "firing up new threads to do the work", but then >> I ran into issues w/ Tapestry's thread local data not being available in >> those other threads when I pass in the variables from my tapestry >> page/component ( I posted in a different thread a few weeks ago about >> that). >> > > This is weird. If you don't pass the component, page or mixin objects > themselves to this other threads, there shouldn't be any problem. Could you > link to the thread please? > > @Lance - thanks for pointing out the fact about the mutability of the DOM >> - AFAIK, Lift snippets are indeed "transformations" of the DOM that they >> manipulate, and from the POV of how Scala deals w/ XML the DOM is treated >> as an immutable structure that goes through a bunch of transformations. >> So, this might be a critical distinction that I missed in my initial thought >> process. >> > > Lift is a Scala framework. Scala favors immutable structures, so this > difference between Lift and Tapestry isn't unexpected to me. > > Anyway, the argument here seems to me like the argument for parallel >> collections (when I first saw them in Groovy for example). My initial >> reaction when I saw them for the first time was "why the heck would I >> want to do this, of course I'd want to go over my collection items one by >> one". >> > > Actually, in some cases, the parallelized version is slower than the > sequential one due to threading overhead. > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
