I've run into this problem on some heavyweight pages using Tap 4.0 and Tacos 4.0. I basically had to modify all my pages so that models are initialized only on access. If I need a model to reinitialize after the rewind cycle, I set it back to null during a listener method. In Tap4.0 + tacos, even that wasn't really enough to get me any efficiency gains, since the whole page must still rewind, so all the models were firing, anyway. At best, I was sparing myself the re-initialization of any models that were updated for the render cycle. I solved this by introducing some infrastructure to my pages such that a model is able to check whether it is needed for render, rewind, both, or neither during ajax (dynamic) updates. I just initialize a dictionary in the .page file or via the InitialValue annotation which specifies which models have which update modes. The advantage of this is that I can serve up empty models during the render phase, even if I needed the correct model during rewind, so that Tap doesn't waste a bunch of cycles spewing lots of options to a null writer.
It was a pretty simple refactoring of my code, but it required lots of typing, since I moved from using astract model getters and setters with an initializer in pageBeginRender calling the set method, to having fully specified getters and setters that check if the stored value is null before creating a new model, but only if is not an ajax update or the model is specified as being needed for the current cycle. Modifying existing pages was a pain in the neck, but working with new pages is very simple. It is yet another declarative thing that isn't checked at compile time, though, although I'm sure if I thought about it, I could concoct a way to fix that. Doesn't seem worth the effort, though, since most of my models are now initialized in a base page class, since any page which don't use a particular model don't suffer the initalization hit, anyway. --sam On 4/3/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
You can call IRequestCycle.getResponseBuilder().isDynamic() to see if it's a dynamic request and skip any heavy operations you don't need to perform. On 4/3/07, Wojtek Ciesielski <[EMAIL PROTECTED]> wrote: > Jesse Kuhnert wrote: > > I don't think "onClick" will be a valid js event name to listen to. In > > this instance it has to be "onclick" . > > Thanks, it could be a reason (I was changing several things at once > trying to fix it so I'm only 90% sure that that's it ;-)). > > And I've noticed that even when @EventListener is added to one component > of a page when it's clicked the whole "rendering" is taking place. By > rendering I mean that pageBeginRender() method of the enclosing page is > being called. As an effect - whole logic responsible for pulling data > for whole page from underlying DB is being called... > > So questions are: > 1. Is there ANY place where behaviour of @EventListener (lifecycle of > involved components) is described? > 2. It seems like a bad optimization if logic for whole page and its > component tree is being called, when I just want to update one widget on > the page... How can I optimize it? > > TIA, > Wojtek > > ---------------------------------------------------------------------- > Masz plan? Potrzebujesz motywacji ? > wejdz na >>> http://link.interia.pl/f1a40 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
