You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Lenny Primak <lp...@hope.nyc.ny.us> on 2011/10/26 01:22:31 UTC
Re: Mixins stop working after a zone update (SOLVED!)
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Mixins stop working after a zone update (SOLVED!)
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
Yes, anything that will get me out of the JavaScript business!
I just started dealing with it and I am getting to despise it!
On Oct 25, 2011, at 8:30 PM, Howard Lewis Ship wrote:
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Mixins stop working after a zone update (SOLVED!)
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <lp...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Mixins stop working after a zone update (SOLVED!)
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
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 <ge...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Mixins stop working after a zone update (SOLVED!)
Posted by Geoff Callender <ge...@gmail.com>.
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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org