This ties into where I expect Tapestry to be heading in 5.4, where you
care less about what the component ids are, and more about structure
(including CSS selectors) that filter up to event handlers on the body
element; it means Tapestry can get out of the business of
micro-managing event handlers ... I'm still thinking about this, and
will be blogging about this direction soon.
On Tue, Oct 25, 2011 at 4:22 PM, Lenny Primak <lpri...@hope.nyc.ny.us> wrote:
> There was an addition of one line:
> $(this.formId).setSubmittingElement($(this.elementId)); // *** ADDED
> otherwise zone gets improperly reloaded
> $(this.formId).onsubmit(); // Submit Ajax form
>
> If you don't add the first line, the form is reloaded improperly after the
> zone update,
> so it doesn't work the second time.
>
> *** This is not documented anywhere, and really hard to debug.
> This needs to be incorporated into the JumpStart, because it's now broken
> there.
>
> --------------------- FIXED CODE ----------------------
> /**
> * Disable Submit button after AJAX Form Submission
> */
>
> var DisableAfterSubmit = Class.create();
> DisableAfterSubmit.prototype = {
> initialize: function(elementId, formId, event) {
> this.formId = formId;
> this.elementId = elementId;
> this.handler = this.doEnable.bindAsEventListener(this);
>
> Event.observe($(elementId), 'click',
> this.doDisable.bindAsEventListener(this));
> },
>
> doDisable: function() {
> $(this.elementId).disable();
>
> if($(this.formId).getStorage().zoneId != null) {
> this.zoneElement = Tapestry.findZoneManager(this.formId).element;
> Event.observe(this.zoneElement, Tapestry.ZONE_UPDATED_EVENT,
> this.handler);
>
> $(this.formId).setSubmittingElement($(this.elementId));
> $(this.formId).onsubmit();
> }
> else {
> $(this.formId).submit();
> }
> },
>
> doEnable: function() {
> $(this.zoneElement).stopObserving(Tapestry.ZONE_UPDATED_EVENT,
> this.handler);
> var element = $(this.elementId);
> if(element != null) {
> $(this.elementId).enable();
> }
> }
> };
>
>
> // Extend the Tapestry.Initializer with a static method that instantiates us
> Tapestry.Initializer.disableAfterSubmit = function(spec) {
> new DisableAfterSubmit(spec.elementId, spec.formId);
> };
>
> On Oct 25, 2011, at 2:12 PM, Lenny Primak wrote:
>
>> Yes, the changing of the client IDs to semi-random ones was what I suspected
>> before
>> (hence my previous thread)
>> but after some debugging, it turns out that the mixin gets initialized
>> after the zone update with the new client IDs correctly
>> and something else is going on.
>> It seems like the AJAX event from the mixin to the server stops working,
>> i.e. onsubmit() winds up doing a no-op even though JS calls the server with
>> the form.
>>
>> On Oct 25, 2011, at 1:26 PM, cqasker wrote:
>>
>>> When you get the ajax response back, did any of ids change? The stuff in the
>>> zone changes but the javascript code from the mixin doesn't . I am not an
>>> expert but thats the only thing I can think of.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
