The problem is that we develop with debug. And in tapestry it prints
out the full generated source of the page as debug, basically making the
first few requests on the webapp totally useless as far as debug goes...
is there any way to make that source easier for us to parse out? move
it to TRACE or move it to a different log category easier for us to turn
on and off?
Howard Lewis Ship wrote:
Tapestry generates warnings about any non-private fields it finds in a
component class, so you might want to keep an eye on the console as
well.
Sometimes I think console warnings are useless as no one ever seems to
see them, only by being "in your face" with a hard exception can you
catch the developers' attention.
On Dec 1, 2007 11:17 AM, Fernando Padilla <[EMAIL PROTECTED]> wrote:
Yeah, they were public. Making all my variables private is one of those
things I do without thinking, and I forgot to check that in this case.
Funny. I don't remember reading about tapestry setting all private
variables to null (or their default values) in the docs. Maybe I
skimmed that part of the docs when I read them a while back.
My apologies, setting them to private and having Tapestry set them to
null should take care of it then.
Howard Lewis Ship wrote:
What possible state would you have to clean up?
Assuming you are using proper instance variables (all private), then
Tapestry already does end-of-request cleanup, resetting all your
fields to correct default values (for those that are not set to fixed
values via an injection).
On Nov 30, 2007 6:34 PM, Fernando Padilla <[EMAIL PROTECTED]> wrote:
The bug we're seeing is that the page context is being set by an
onActivate call, but it's never being cleaned up. So the next page
render still has the old page context setup, and we don't have a chance
to re-null it.
normally while handling a page:
onActivate
setupRender
...
cleanupRender
We can absorb the context and cleanup anything that needs to be cleaned
up within the "cleanupRender". But for ComponentActions, there is no
such "cleanup" method available:
onActivate
onAction
Proposed solution is really easy, just add an "onDeactivate" event.
Allowing us to undo any page activation.
ideas?
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
