Oh wow, I never thought of that.. so it was racing between triggering
the zone event and the form submission then I'm guessing? I tried moving
a single breakpoint to the ZoneManager call and then resuming the JS
again. That wasn't working in Firebug, the only way was if I stepped
past the ZoneManager call before resuming. That was enough for me to
believe it was some timing problem.
I inserted some simple JS after the ZoneManager call that wastes half a
second of time. That seemed to be ample time to allow the ZoneManager
update to trigger the event before the form submission. Do you think 500
ms is excessive waiting time here?
Thanks for pointing that out, Josh, would have never occurred to me!
thanks,
Rich
On 01/25/2011 09:27 PM, Josh Canfield wrote:
Sounds like it could be a timing issue. Have you tried putting debug
statements around the in code instead of stepping through with the
debugger?
Sometimes slowly stepping through code gives things a chance to
complete that wouldn't otherwise, possibly it runs fast enough on your
local machine that you don't notice the problem?
Josh
On Tue, Jan 25, 2011 at 11:13 AM, Rich M<rich...@moremagic.com> wrote:
Hi,
I wrote up a mixin that does delete confirmation. I'd put it through testing
a while back and everything seemed fine. Recently it has turned up that it's
functioning very strangely.
On my local machine, it runs as expected. I take in parameters from a TML
declaration of the mixin on a Submit button. I have it bind via Prototype to
the mouseup event to fire a method that returns via AJAX back to the Page
class. An event handler in the Page class reads the parameter from the
Request and determines whether or not the user decided to Delete or not.
This value is persisted, and in the event handler method for the form
itself, it will bypass deletion based on this boolean.
Clicking cancel cancels out of the deletion. Clicking okay continues through
with the deletion.
Now its different a production server, which is no different that local
other than that it is deployed as a WAR rather than using mvn jetty:run.
Here if you just navigate to the page, the event handler in the Page class
for the AJAX/ZoneUpdater is never called.... unless you use Firebug and walk
through the Javascript method that feeds the update request. In every single
case using Firebug to walk through, the event handler in the Page class DOES
get called. Note that it always pops up a Javascript confirm box, but only
hooks up through the ZoneUpdater event handler if I walk through in Firebug.
I'm pretty baffled as to why walking through in Firebug gets the call to
work, but standard browser operation doesn't.
For clarification, the life-cycle of the persisted Boolean in the Page class
that the form uses is as follows:
@Persist private Boolean delete_confirm;
onPrepare() -> if delete_confirm == null then delete_confirm = false; // to
prevent accidental deletes
onDeleteConfirm() -> ZoneUpdater event handler, delete_confirm =
Boolean.parseBoolean(request_parameter);
onSuccessFromForm() -> if(!delete_confirm) return; //exit out of form if we
arent confirming the deletion
Any insight?
Thanks,
Rich
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
