I know about mechanics of Future and other java.utils.concurrent. I don't know how it helps to solve my question.
Future.get() is just a kind of blocking call. If i have two independent components, i should call Future.get() two times in their setupRender. So i get two consecutive delays. Overall delay would be summ of separate delays for each component. The question is really about Tapestry rendering pipeline. I need iterate over all components in page before they start render, to send remote requests. On Tue, Apr 14, 2015 at 9:57 PM, Thiago H de Paula Figueiredo < thiag...@gmail.com> wrote: > On Tue, 14 Apr 2015 11:08:11 -0300, Тимур Бухараев <bukhar...@gmail.com> > wrote: > > I don't know how to solve my problem with Future. If you know, explain >> please. >> > > That's not a Tapestry-specific question, so I suggest you to find and read > tutorials like this: http://java.dzone.com/articles/ > javautilconcurrentfuture. > > ProgressiveDisplay is a solution, but has some disadvantages. >> > > Yep. But it does fit in many situations, so I think it should be an option > you have in mind when thinking about specific components. > > Now about moving data fetch logic. >> >> The problem is components are independent. Page class doesn't know about >> Component classes, component classes don't know about page and other >> components. They just embedded in a single tml document. So designer >> could move component to other place, and it still works. Each component >> fetches >> his own remote data independently. I can cache this data in service, if >> some components need same data, so the second component get cached data. >> But component is the only place who knows, what data it needs. For >> example, component displaying user profile. It needs user profile data, and >> it >> fetches it. So component is the only thing who knows it need profile >> data. But i can embed it in any tml in any place. >> > > Ok! Of course, one solution doesn't cover all situations, and the service > one doesn't cover yours. > > Some time ago there was a discussion about parallel rendering of > components in this mailing list. My conclusion of it it's that it can be > done, but you have to be extra-extra-extra careful. > http://apache-tapestry-mailing-list-archives.1045711. > n5.nabble.com/quot-Parallel-quot-component-rendering-td5729024.html. It's > a very interesting read, with lots of interesting opinions. > > I have one different suggestion now: cache the results of these slow > method calls so, the next time you have to make one, you already have the > result ready. Of course, caching should be done very carefully, when when > it's done, it does wonders for performance and request times. > > > -- > 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 > >
