I don't off the top of my head. I bet every piece of JS code that does
onsubmi()t is broken.
On Oct 26, 2011, at 6:24 AM, Geoff Callender
<geoff.callender.jumpst...@gmail.com> wrote:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
