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
