> 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.
I just re-read your original post. Are you canceling the form submit when you handle the mouseup? > 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? I'm not sure how you're code works, but instead I'd fix the issue by preventing the form from being submitted when you capture the mouseup, and then do the re-post the form in Javascript when you know it's what needs to get done. Putting in pauses is the kind of workaround that's likely to bite you later when the timing changes again. I seem to recall something like this coming up on the list before, there might be existing code for an ajax enabled confirmation dialog. A quick google didn't find it, but you might have more luck if you're more persistent. Josh On Wed, Jan 26, 2011 at 8:20 AM, Rich M <rich...@moremagic.com> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
