Hello Everyone, Is there any prototype patch available that would enable the following - 1) Passing a ''timeout'' parameter to the ajax.request so that we can timeout every request after some seconds. Every request could have a different timeout associated. 2) Addition of onTimeout method where we could do some handling? A simple solution is available on codejanitor.com but before using that and writing our own, just want to check if there already is a patch on this. Thank you, Mandy.
Maninder, Singh wrote:> Hello Everyone, > > Is there any prototype patch available that would enable the following - > > 1) Passing a ''timeout'' parameter to the ajax.request so that we can timeout every request after some seconds. > Every request could have a different timeout associated. > > 2) Addition of onTimeout method where we could do some handling? > > A simple solution is available on codejanitor.com but before using that and writing our own, just want to check if there already > is a patch on this.http://dev.rubyonrails.org/ticket/3730 http://www.brainsick.com/prototype/requestTimeout.patch/ I haven''t looked at it since February, but I''d imagine it still works; Prototype hasn''t changed much. Todd Ross
Lovely! Taking a look now. Thanks Todd. -Mandy.
Todd, Your solution works perfect for me (from the first round of testing that I have done). There is just one small issue - Currently, I have made changes to my prototype file. But, this means that tomorrow if new version of prototype comes out, it''s going to be a pain maintaining it. What do you suggest - should we extend and add these lines (which would mean duplicating a lot and still no guarantee of not making changes in the future)? I wish Sam would incorporate this. Thanks, Mandy.
Mandy... Can the changed lines/classes you''re talking about be factored out into a separate "prototype-overrides.js" file which you can load into the docuement after prototype.js is loaded, thus overwriting (or Object.extending) the existing classes with your added functionality, but still allowing you to keep a core prototype file that matches the official trunk? ...just a thought. On 7/19/06, Maninder, Singh <mandiv-W2hqgAdRMsX2eFz/2MeuCQ@public.gmane.org> wrote:> > Todd, > > Your solution works perfect for me (from the first round of testing that I > have done). > > There is just one small issue - > > Currently, I have made changes to my prototype file. > But, this means that tomorrow if new version of prototype comes out, it''s > going to be a pain maintaining it. > > What do you suggest - should we extend and add these lines (which would > mean duplicating a lot and still no guarantee of not making changes in the > future)? > > I wish Sam would incorporate this. > > Thanks, > Mandy. > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Maninder, Singh wrote:> Your solution works perfect for me (from the first round of testing that I have done).I''m glad to hear that.> There is just one small issue - > > Currently, I have made changes to my prototype file. > But, this means that tomorrow if new version of prototype comes > out, it''s going to be a pain maintaining it.I''ve taken a very strong position on this issue in the past; offering code out-of-tree is creating maintenance burdens for the people who adopt it. I am, however, making every effort (specifically, I''ve filed a bug report with a patch ready to review) to get this code included into Prototype proper. It''s your decision on whether you choose to adopt it or to come up with an alternative solution. You asked for a patch and I provided. :)> What do you suggest - should we extend and add these lines (which > would mean duplicating a lot and still no guarantee of not making > changes in the future)?Personally, I feel that patching prototype.js for a change like this (it''s not a fringe change; it makes changes to core parts of Ajax.Request) is the best approach. Ryan suggested that maybe it could be reworked as a separate include. You two are welcome to try. Please post your solutions if you choose to pursue it.> I wish Sam would incorporate this.In the FIVE MONTHS that this patch has been available, it''s not received a single comment from Sam or other developers / users. If you''d like to see it included, then I''d suggest you add a "me too"/"tested" comment to the bug report. That is, once dev.rubyonrails.org is back on-line. Todd Ross
Going back to the Parenizor debate we had here a few weeks ago (I tried to
do a search for that thread on http://www.ruby-forum.com/forum/10 but the
search function is currently broken, meh)...
One could cache the old (core) proto class in question into a "base"
property of the new class before extending and overriding, and then do a
check against required conditions to execute the new code, otherwise apply
the old method...
Here is the code I posted to solve the Parenizor problem (from the Douglas
Crockford site) in prototype... this type of technique could easily be
applied to overriding the prototype core classes in a maintanable manner...
just be sure you do your due diligence and regression test your changes.
Parenizor = Class.create();
Parenizor.prototype {
initialize: function(value)
{
this.setValue (value);
},
setValue: function(value)
{
this.value = value;
},
getValue: function()
{
return this.value;
},
_toString: function()
{
return "(" + this.value + ")";
}
};
ZParenizor = Class.create();
ZParenizor.prototype {
initialize: function(value)
{
//cache the super class
this.base = new Parenizor(value);
//inherit
Object.extend(this, this.base);
//override
Object.extend(this,
{
_toString: function()
{
if (this.getValue())
return this.base._toString();
return "-0-";
}.bind(this)
});
}
};
alert(new ZParenizor(5)._toString());
alert(new ZParenizor()._toString());
On 7/19/06, Todd Ross
<rails-spinoffs-25kFIyuv2iRiLUuM0BA3LQ@public.gmane.org>
wrote:>
> Maninder, Singh wrote:
> > Your solution works perfect for me (from the first round of testing
that
> I have done).
>
> I''m glad to hear that.
>
> > There is just one small issue -
> >
> > Currently, I have made changes to my prototype file.
> > But, this means that tomorrow if new version of prototype comes
> > out, it''s going to be a pain maintaining it.
>
> I''ve taken a very strong position on this issue in the past;
offering
> code out-of-tree is creating maintenance burdens for the people who
> adopt it. I am, however, making every effort (specifically, I''ve
filed
> a bug report with a patch ready to review) to get this code included
> into Prototype proper. It''s your decision on whether you choose
to
> adopt it or to come up with an alternative solution. You asked for a
> patch and I provided. :)
>
> > What do you suggest - should we extend and add these lines (which
> > would mean duplicating a lot and still no guarantee of not making
> > changes in the future)?
>
> Personally, I feel that patching prototype.js for a change like this
> (it''s not a fringe change; it makes changes to core parts of
> Ajax.Request) is the best approach. Ryan suggested that maybe it could
> be reworked as a separate include. You two are welcome to try. Please
> post your solutions if you choose to pursue it.
>
> > I wish Sam would incorporate this.
>
> In the FIVE MONTHS that this patch has been available, it''s not
received
> a single comment from Sam or other developers / users. If you''d
like to
> see it included, then I''d suggest you add a "me
too"/"tested" comment to
> the bug report. That is, once dev.rubyonrails.org is back on-line.
>
> Todd Ross
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Todd, Your solution doesn''t work in Safari. As per the Gentleman who helped me test this, after aborting the request, onComplete is not getting fired in Safari. We have put a hack round it by explicitly calling it after aborting. But, just wanted you to be in the loop. Thanks for a great patch. -Mandy.
Maninder, Singh wrote:> Your solution doesn''t work in Safari. > > As per the Gentleman who helped me test this, after aborting > the request, onComplete is not getting fired in Safari.I''m sorry to hear that but thanks for the report! I don''t have access to a machine with Safari, I''m afraid. Can I trouble you to add a comment to the bug so that others are aware of the problem? Someone might post an alternative patch then as well. http://dev.rubyonrails.org/ticket/3730 Todd Ross