You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Wojtek Ciesielski <cc...@interia.pl> on 2007/04/03 15:40:02 UTC

It's working now - but HOW does it work? ;-)

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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: It's working now - but HOW does it work? ;-)

Posted by Sam Gendler <sg...@ideasculptor.com>.
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 <jk...@gmail.com> 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 <cc...@interia.pl> 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: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> --
> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: It's working now - but HOW does it work? ;-)

Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <cc...@interia.pl> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>


-- 
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org