Hi Lenny,
Thanks for raising this. Are there any examples in JumpStart that you know are
broken (I can't find any)? And are there examples that you think will not work
if put inside a zone?
I will think about a simple example to highlight the danger (and would be happy
to hear suggestions for a simple example).
Cheers,
Geoff
On 26/10/2011, at 10:22 AM, Lenny Primak 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
