Hello Is it possible to reuse already existent Ajax.Request? Something like this: var req = new Ajax.Request(url,[options]); <code or smth...> req.restart; // possible? I want to avoid creating (XMLHttpRequest || Microsoft.XMLHTTP) object for each call. It is just about performance.. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Hey again, toapole maktonk a écrit :> I want to avoid creating (XMLHttpRequest || Microsoft.XMLHTTP) object > for each call. It is just about performance..Actually, it might be a non-issue: - A webapp relying on 10+ XHR''s per second is likely to be extremely resource-hogging and very difficult to fine-tune from an ergonomical standpoint. - XHR creation cost is fairly minimal (certainly way beyond 100ms), so for a "reasonable" use of XHR (say, out of my hat, <= 3/s.), is that really going to be an issue? Now, technically, XHR allows reuse, providing it''s properly used (IE6 mandates a specific order for calling XHR methods on a reused XHR object, I believe). Ajax.Request does, I believe, call XHR methods in the proper order, so this is not an issue. Ajax.Request'' fundamental requesting method is simply "request," which takes the URL. However, it relies on the options having been defined at creation time. If that''s okay with you, you can probably try using request directly... Haven''t tried. -- Christophe Porteneuve aka TDD tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
I agree with Christophe on the fact that just using the Ajax.Request class every time you want to make an XHR request is pretty much the best possible way to handle this... however, you CAN reuse it if that''s what you want to do. Assuming that you have a request that you want to make over and over again with the same options each time, you can do this: var xhr = new Ajax.Request(''somePage.html'',{ onComplete: function(req) { alert(''success''); } }); To re-request with that request, you can do: xhr.request(''somePage.html''); However, even though the request fires successfully, it will not execute your onComplete function. The reason is because that request object has a value called _complete that is set to true once the onComplete fires the first time. To work around this behavior, simply set it to false before each request. xhr._complete = false; xhr.request(''somePage.html''); Enjoy... -E On 2/23/07, Christophe Porteneuve <tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org> wrote:> > Hey again, > > toapole maktonk a écrit : > > I want to avoid creating (XMLHttpRequest || Microsoft.XMLHTTP) object > > for each call. It is just about performance.. > > Actually, it might be a non-issue: > > - A webapp relying on 10+ XHR''s per second is likely to be extremely > resource-hogging and very difficult to fine-tune from an ergonomical > standpoint. > > - XHR creation cost is fairly minimal (certainly way beyond 100ms), so > for a "reasonable" use of XHR (say, out of my hat, <= 3/s.), is that > really going to be an issue? > > Now, technically, XHR allows reuse, providing it''s properly used (IE6 > mandates a specific order for calling XHR methods on a reused XHR > object, I believe). Ajax.Request does, I believe, call XHR methods in > the proper order, so this is not an issue. > > Ajax.Request'' fundamental requesting method is simply "request," which > takes the URL. However, it relies on the options having been defined at > creation time. If that''s okay with you, you can probably try using > request directly... Haven''t tried. > > -- > Christophe Porteneuve aka TDD > tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org > > > >-- Eric Ryan Harrison --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
I''ve actually tried to do this (the reusing of Request objects) and run into a lot of problems. Specifically, if you end up making Request1 and Request2 but Request2 finishes prior to Request1 all sorts of strange things were happening with respect to the callback functions. If you get it working, more power to you, but I third the response of the others saying just use multiple objects :) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---