Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #15725 > unrolled thread

XHR: Passing Parameters to a ready-state-change Function

Back to article view | Back to comp.lang.javascript

Contents

  XHR: Passing Parameters to a ready-state-change Function Gene Wirchenko <genew@ocis.net> - 2012-09-05 13:53 -0700
    Re: XHR: Passing Parameters to a ready-state-change Function Jim T. <x@y.z> - 2012-09-05 17:46 -0400
      Re: XHR: Passing Parameters to a ready-state-change Function Gene Wirchenko <genew@ocis.net> - 2012-09-05 17:30 -0700
        Re: XHR: Passing Parameters to a ready-state-change Function Jim T. <x@y.z> - 2012-09-05 20:55 -0400
    Re: XHR: Passing Parameters to a ready-state-change Function Jim T. <x@y.z> - 2012-09-05 21:43 -0400
      Re: XHR: Passing Parameters to a ready-state-change Function Jim T. <x@y.z> - 2012-09-05 21:49 -0400
    Re: XHR: Passing Parameters to a ready-state-change Function Stefan Weiss <krewecherl@gmail.com> - 2012-09-06 18:56 +0200
      Re: XHR: Passing Parameters to a ready-state-change Function Gene Wirchenko <genew@ocis.net> - 2012-09-06 10:55 -0700
      Re: XHR: Passing Parameters to a ready-state-change Function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-06 21:38 +0200
        Re: XHR: Passing Parameters to a ready-state-change Function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-06 21:49 +0200
      Re: XHR: Passing Parameters to a ready-state-change Function Gene Wirchenko <genew@ocis.net> - 2012-09-06 15:49 -0700
        Re: XHR: Passing Parameters to a ready-state-change Function Tim Streater <timstreater@greenbee.net> - 2012-09-07 09:15 +0100
          Re: XHR: Passing Parameters to a ready-state-change Function Gene Wirchenko <genew@ocis.net> - 2012-09-07 09:58 -0700
            Re: XHR: Passing Parameters to a ready-state-change Function Tim Streater <timstreater@greenbee.net> - 2012-09-07 19:14 +0100
              Re: XHR: Passing Parameters to a ready-state-change Function cezary.tomczyk@gmail.com - 2012-09-07 13:51 -0700
                Re: XHR: Passing Parameters to a ready-state-change Function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-08 00:52 +0200
                  Re: XHR: Passing Parameters to a ready-state-change Function cezary.tomczyk@gmail.com - 2012-09-07 16:32 -0700
                    Re: XHR: Passing Parameters to a ready-state-change Function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-08 09:48 +0200
                      Re: XHR: Passing Parameters to a ready-state-change Function Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-09-08 02:09 -0700
                    Re: XHR: Passing Parameters to a ready-state-change Function Tim Streater <timstreater@greenbee.net> - 2012-09-08 11:09 +0100
                      Re: XHR: Passing Parameters to a ready-state-change Function Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-09-08 03:39 -0700
                  Re: XHR: Passing Parameters to a ready-state-change Function John G Harris <john@nospam.demon.co.uk> - 2012-09-08 15:00 +0100
              Re: XHR: Passing Parameters to a ready-state-change Function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-07 23:44 +0200
                Re: XHR: Passing Parameters to a ready-state-change Function Tim Streater <timstreater@greenbee.net> - 2012-09-07 23:08 +0100
                  Re: XHR: Passing Parameters to a ready-state-change Function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-08 00:46 +0200
                    Re: XHR: Passing Parameters to a ready-state-change Function Tim Streater <timstreater@greenbee.net> - 2012-09-08 11:11 +0100
                      Re: XHR: Passing Parameters to a ready-state-change Function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-08 14:21 +0200
                        Re: XHR: Passing Parameters to a ready-state-change Function Tim Streater <timstreater@greenbee.net> - 2012-09-08 17:06 +0100
                          Re: XHR: Passing Parameters to a ready-state-change Function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-08 20:41 +0200
                            Re: XHR: Passing Parameters to a ready-state-change Function Dr J R Stockton <reply1236@merlyn.demon.co.uk.invalid> - 2012-09-09 20:04 +0100
              Re: XHR: Passing Parameters to a ready-state-change Function Gene Wirchenko <genew@ocis.net> - 2012-09-09 18:40 -0700
                Re: XHR: Passing Parameters to a ready-state-change Function "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-09-10 07:21 +0000
                Re: XHR: Passing Parameters to a ready-state-change Function Tim Streater <timstreater@greenbee.net> - 2012-09-10 09:03 +0100
                  Re: XHR: Passing Parameters to a ready-state-change Function "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-09-10 13:59 +0000
                    Re: XHR: Passing Parameters to a ready-state-change Function Tim Streater <timstreater@greenbee.net> - 2012-09-10 15:35 +0100
                      Re: XHR: Passing Parameters to a ready-state-change Function "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-09-10 22:42 +0000
                        Re: XHR: Passing Parameters to a ready-state-change Function Scott Sauyet <scott.sauyet@gmail.com> - 2012-09-11 10:09 -0700
                          Re: XHR: Passing Parameters to a ready-state-change Function Tim Streater <timstreater@greenbee.net> - 2012-09-11 22:42 +0100

Page 2 of 2 — ← Prev page 1 [2]

#15797

W dniu sobota, 8 września 2012 12:09:03 UTC+2 użytkownik Tim Streater napisał:
> In article <e22caa6d-0b21-46ea-bf5f-2db6f561e9ca@googlegroups.com>,
> 
>  cezary.tomczyk@gmail.com wrote:
> 
> > So, if server will response with 304 header then XHR will return status 200 
> 
> > or 304? Because if all XHR implementations handle caching transparently then 
> 
> > just checking only status == 200 is not a good idea. Or I something missed.
> 
> I've had status==0, but that was probably a Safari 5.0 bug (about which 
> 
> I had discussions with Apple Engineering and more recent versions have 
> 
> not suffered from).

BTW I see that Thomas Lahn in his code http://pointedears.de/scripts/http.js have a nice solution to check the response status.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#15799

On Sat, 8 Sep 2012 at 00:52:33, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:
>cezary.tomczyk@gmail.com wrote:
>
>> W dniu pi0 >> napisa0 >
>It's an attribution _line_, not an attribution novel.
  <snip>

It's called 'attribution' in my news reader. Where do you get 'line'
from?

  John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#15784

Tim Streater wrote:

> Gene Wirchenko <genew@ocis.net> wrote:
>> > By the way, as has been pointed out you need to check that status==200
>> > also. You also need to set xhr = null when you've finished with it.
>> 
>>      I know about 200.

Do you know about 0 and 1223 (sic!) as well?

>>      Setting xhr to null?  Why?  I may well be using it again.  The
>> forms are CRUD and so there may be multiple transactions go to the
>> server.

ACK.

> And each time you call your ajax function you'll get a new one.

Which is not a bad thing.

> AIUI, although my knowledge of closures is a bit limited, each one will
> live forever unless you explicitly dump it when you've finished with it.
> By setting it to null, it'll get garbage-collected subsequently.

Wishful thinking.  There is no guarantee that garbage collection will 
commence before all browser windows are closed.
 
> Here's what I do (slightly simplified, as I log the status error rather
> than just alert-ing):
> 
> function ajax (url, data, callbackFunction)
>      {
> 
>      var request = window.XMLHttpRequest ? new XMLHttpRequest () : new
> ActiveXObject ("MSXML2.XMLHTTP.3.0");
> 
>      request.open ("post", url, true);
>      request.setRequestHeader ("Content-Type",
> "application/x-www-form-urlencoded; charset=utf-8");
>  
>      request.onreadystatechange = function ()
>           {
> 
>           if  (request.readyState!=4)  return;
> 
>           if  (request.status==200 && request.responseText!="")
> callbackFunction (request.responseText);
>           if  (request.status!=200)  alert ("Bad ajax status: " +
> request.status);
> 
>           request = null;

With regard to memory efficiency and probably even runtime efficiency, it
is far better to reuse an existing XHR object once the request has been 
processed.  See JSX:http.js [1] for example.
 
>           };
> 
>      request.send (data);

`data' needs to be transfer-encoded; with this Content-Type header field 
value and without a Transfer-Encoding header field, it needs to be percent-
encoded:

  request.send(encodeURI(data));

But you might want to encodeURIComponent() each name an value separately 
instead.


PointedEars
___________
[1] 
<http://pointedears.de/websvn/filedetails.php?repname=JSX&path=%2Ftrunk%2Fhttp.js>
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#15785

In article <1399593.26SQpm16Mm@PointedEars.de>,
 Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:

> Tim Streater wrote:

> > And each time you call your ajax function you'll get a new one.
> 
> Which is not a bad thing.
> 
> > AIUI, although my knowledge of closures is a bit limited, each one will
> > live forever unless you explicitly dump it when you've finished with it.
> > By setting it to null, it'll get garbage-collected subsequently.

I leave that to the browser to worry about.

> Wishful thinking.  There is no guarantee that garbage collection will 
> commence before all browser windows are closed.

[snip]

> >           request = null;
> 
> With regard to memory efficiency and probably even runtime efficiency, it
> is far better to reuse an existing XHR object once the request has been 
> processed.  See JSX:http.js [1] for example.

No doubt, but I may have several such requests outstanding at any given 
moment and have no desire to manage a set of XHR objects.

> >           };
> > 
> >      request.send (data);
> 
> `data' needs to be transfer-encoded; with this Content-Type header field 
> value and without a Transfer-Encoding header field, it needs to be percent-
> encoded:
> 
>   request.send(encodeURI(data));
> 
> But you might want to encodeURIComponent() each name an value separately 
> instead.

I do, in fact.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#15786

Tim Streater wrote:

>  Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>> Tim Streater wrote:
>> > And each time you call your ajax function you'll get a new one.
>> Which is not a bad thing.
>> 
>> > AIUI, although my knowledge of closures is a bit limited, each one will
>> > live forever unless you explicitly dump it when you've finished with
>> > it. By setting it to null, it'll get garbage-collected subsequently.
> 
> I leave that to the browser to worry about.

IOW, you are incompetent enough to not care about your users.

>> Wishful thinking.  There is no guarantee that garbage collection will
>> commence before all browser windows are closed.
> 
> [snip]
> 
>> >           request = null;
>> 
>> With regard to memory efficiency and probably even runtime efficiency, it
>> is far better to reuse an existing XHR object once the request has been
>> processed.  See JSX:http.js [1] for example.
> 
> No doubt, but I may have several such requests outstanding at any given
> moment and have no desire to manage a set of XHR objects.

So you would rather not manage them and let them waste memory, one by one, 
eating it up until the browser application exits, in the worst case.  Where 
is the logic in that?
 

PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#15796

In article <1704778.3LbdHo29L0@PointedEars.de>,
 Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:

> Tim Streater wrote:
> 
> >  Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
> >> Tim Streater wrote:
> >> > And each time you call your ajax function you'll get a new one.
> >> Which is not a bad thing.
> >> 
> >> > AIUI, although my knowledge of closures is a bit limited, each one will
> >> > live forever unless you explicitly dump it when you've finished with
> >> > it. By setting it to null, it'll get garbage-collected subsequently.
> > 
> > I leave that to the browser to worry about.
> 
> IOW, you are incompetent enough to not care about your users.

Fuck off.

> >> Wishful thinking.  There is no guarantee that garbage collection will
> >> commence before all browser windows are closed.
> > 
> > [snip]
> > 
> >> >           request = null;
> >> 
> >> With regard to memory efficiency and probably even runtime efficiency, it
> >> is far better to reuse an existing XHR object once the request has been
> >> processed.  See JSX:http.js [1] for example.
> > 
> > No doubt, but I may have several such requests outstanding at any given
> > moment and have no desire to manage a set of XHR objects.
> 
> So you would rather not manage them and let them waste memory, one by one, 
> eating it up until the browser application exits, in the worst case.  Where 
> is the logic in that?

They don't waste memory, they get garbage collected. If I didn't set 
them to null they certainly would waste memory.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#15798

Tim Streater wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>> Tim Streater wrote:
>> >  Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>> >> Tim Streater wrote:
>> >> > And each time you call your ajax function you'll get a new one.
>> >> Which is not a bad thing.
>> >> 
>> >> > AIUI, although my knowledge of closures is a bit limited, each one
>> >> > will live forever unless you explicitly dump it when you've finished
>> >> > with it. By setting it to null, it'll get garbage-collected
>> >> > subsequently.
>> > I leave that to the browser to worry about.
>> IOW, you are incompetent enough to not care about your users.
> 
> Fuck off.

Why I am even talking to you?  You were incompetent when I scorefiled you 
years ago and you have not changed a bit.  See below.

>> >> Wishful thinking.  There is no guarantee that garbage collection will
>> >> commence before all browser windows are closed.
>> > 
>> > [snip]
>> > 
>> >> >           request = null;
>> >> 
>> >> With regard to memory efficiency and probably even runtime efficiency,
>> >> it is far better to reuse an existing XHR object once the request has
>> >> been
>> >> processed.  See JSX:http.js [1] for example.
>> > 
>> > No doubt, but I may have several such requests outstanding at any given
>> > moment and have no desire to manage a set of XHR objects.
>> 
>> So you would rather not manage them and let them waste memory, one by
>> one,
>> eating it up until the browser application exits, in the worst case. 
>> Where is the logic in that?
> 
> They don't waste memory, they get garbage collected.

When?  *That* is the question you have to ask yourself, and the answer to 
that is: You *cannot* know.  So be slow to create new objects.

> If I didn't set them to null they certainly would waste memory.

You have a serious misconception of how these implementations work and how 
garbage collection works, in general.  Which is unsurprising given your 
statement on the top (and yet you still think you know what is going on?).

If you are assigning `null' or any other non-reference value to a property, 
what you are doing is merely to reduce the number of references to an 
object.  (Because, you know, an object can have, and usually will have, 
*several* references to it.  References are values here.)

If, and only if, the number of references to an object reaches zero, the 
object becomes eligible for garbage collection (that is, the memory it uses 
can be freed, to be used by other data).  It can (but does not need to) be 
*marked* for garbage collection then.

When garbage collection actually happens, the memory reserved for *marked* 
objects is freed.  Not before.  In the best case, garbage collection happens 
when cyclically, defined by a probability algorithm, the engine cleans up 
after itself.  The medium case is that garbage collection happens only when 
the engine runs out of free memory.  In the worst case, it happens only when 
the engine is terminated, which is when the browser process is terminated 
(i.e., all windows are closed).

This is not a fantasy.  There have been and still are badly designed Web 
applications using client-side scripting eating up memory until the browser 
and operating system became virtually unusable (driving the swap size to the 
extreme) because people were not aware of the objects and closures they 
created and the applications and browsers ran for a longer time.

Bottom line: Creating objects in the current browser session reserves 
memory.  Creating more objects reserves more memory.  Reserving memory 
reduces free memory.  Assigning `null' to a property that previously had as 
value a reference to an object does _not_ *immediately* free that memory.  
It certainly does _not_ *trigger* garbage collection.  It merely *allows* 
for garbage collection, if, and only if, all conditions I mentioned above 
are met.


PointedEars
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

[toc] | [prev] | [next] | [standalone]

#15800

In article <1908140.bfDClWI3Sb@PointedEars.de>,
 Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:

> Tim Streater wrote:
> 
> > Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
> >> Tim Streater wrote:
> >> >  Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
> >> >> Tim Streater wrote:
> >> >> > And each time you call your ajax function you'll get a new one.
> >> >> Which is not a bad thing.
> >> >> 
> >> >> > AIUI, although my knowledge of closures is a bit limited, each one
> >> >> > will live forever unless you explicitly dump it when you've finished
> >> >> > with it. By setting it to null, it'll get garbage-collected
> >> >> > subsequently.
> >> > I leave that to the browser to worry about.
> >> IOW, you are incompetent enough to not care about your users.
> > 
> > Fuck off.
> 
> Why I am even talking to you?

I'd really rather you didn't. I was going to add that you exhibit the 
manners of a pig, but then I realised that would be rude to the pig. I 
suggest that you leave the classroom, go and look for your manners, and 
let us know when you find them.

> > If I didn't set them to null they certainly would waste memory.
> 
> You have a serious misconception of how these implementations work and how 
> garbage collection works, in general.  Which is unsurprising given your 
> statement on the top (and yet you still think you know what is going on?).

I do know what's going on, in general terms, but not the details of what 
a particular implementation will do. Your long description, however, 
contains nothing I didn't already know.

Now go away, and don't bother me again until you learn some manners.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#15801

Tim Streater wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>> > If I didn't set them to null they certainly would waste memory.
>> 
>> You have a serious misconception of how these implementations work and
>> how garbage collection works, in general.  Which is unsurprising given
>> your statement on the top (and yet you still think you know what is going
>> on?).
> 
> I do know what's going on, in general terms,

No, you do not.  In short, your notion that assigning `null' would *trigger* 
garbage collection, and that therefore it would free memory, is utter 
nonsense.

> Your long description, however, contains nothing I didn't already know.

I am quite sure you did not even bother to read it.

> Now go away, and don't bother me again until you learn some manners.

Pot, kettle, black.


PointedEars
-- 
When all you know is jQuery, every problem looks $(olvable).

[toc] | [prev] | [next] | [standalone]

#15808

In comp.lang.javascript message <1852241.FvrK0BrAjE@PointedEars.de>,
Sat, 8 Sep 2012 20:41:49, Thomas 'PointedEars' Lahn <PointedEars@web.de>
posted:

>Tim Streater wrote:

>> Your long description, however, contains nothing I didn't already know.
>
>I am quite sure you did not even bother to read it.
>
>> Now go away, and don't bother me again until you learn some manners.
>
>Pot, kettle, black.

Little Tommy will have a tantrum, if we are careful.

-- 
 (c) John Stockton, nr London, UK.  Mail via homepage.  Turnpike v6.05  MIME.
  Web  <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and links;
  Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
 No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

[toc] | [prev] | [next] | [standalone]

#15810

On Fri, 07 Sep 2012 19:14:01 +0100, Tim Streater
<timstreater@greenbee.net> wrote:

>In article <mf9k489u8j684s2unrfbaaq62idmti1dsi@4ax.com>,
> Gene Wirchenko <genew@ocis.net> wrote:
>
>> >By the way, as has been pointed out you need to check that status==200 
>> >also. You also need to set xhr = null when you've finished with it.
>> 
>>      I know about 200.
>> 
>>      Setting xhr to null?  Why?  I may well be using it again.  The
>> forms are CRUD and so there may be multiple transactions go to the
>> server.
>
>And each time you call your ajax function you'll get a new one. AIUI, 
>although my knowledge of closures is a bit limited, each one will live 
>forever unless you explicitly dump it when you've finished with it. By 
>setting it to null, it'll get garbage-collected subsequently.

     Ah, now I understand you.  I do not think I have that problem
since my XHR object is a global.  I decided to do this since I am only
going to have one.

     I do not understand closures myself.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#15812

Gene Wirchenko wrote on 10 sep 2012 in comp.lang.javascript:

> I do not understand closures myself.

Me too, so I hold not to need those damn things at all.

Many say:

even while it is all in the <head>,
you have to see the <body> to get closure.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#15813

In article <u3hq485sc5rre4spos8e79b02pm3691mpd@4ax.com>,
 Gene Wirchenko <genew@ocis.net> wrote:

> On Fri, 07 Sep 2012 19:14:01 +0100, Tim Streater
> <timstreater@greenbee.net> wrote:
> 
> >In article <mf9k489u8j684s2unrfbaaq62idmti1dsi@4ax.com>,
> > Gene Wirchenko <genew@ocis.net> wrote:
> >
> >> >By the way, as has been pointed out you need to check that status==200 
> >> >also. You also need to set xhr = null when you've finished with it.
> >> 
> >>      I know about 200.
> >> 
> >>      Setting xhr to null?  Why?  I may well be using it again.  The
> >> forms are CRUD and so there may be multiple transactions go to the
> >> server.
> >
> >And each time you call your ajax function you'll get a new one. AIUI, 
> >although my knowledge of closures is a bit limited, each one will live 
> >forever unless you explicitly dump it when you've finished with it. By 
> >setting it to null, it'll get garbage-collected subsequently.
> 
>      Ah, now I understand you.  I do not think I have that problem
> since my XHR object is a global.  I decided to do this since I am only
> going to have one.
> 
>      I do not understand closures myself.

:-)

Yes, if you only have one that is quite adequate. In my app I have 118 
calls to my ajax function.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#15815

Tim Streater wrote on 10 sep 2012 in comp.lang.javascript:

> Yes, if you only have one that is quite adequate. In my app I have 118 
> calls to my ajax function.

If they are triggered by seperate user actions, 
then it stil is one at a time.

If there are 118 in one action, that seems not efficient, 
why not join them to one single Ajax exchange?

When using Ajax, one should always ask onself first,
what should be acccmplished?

Meseema there are only 3 reasons:

1 the data are not ready when the page loads, 
and waiting for those data as a regular part of the page 
is not an option.

2 the data depend on user action.

3 the data are to be refreshed after a timeout.

4 the data are fetched severside from different sources, 
which insividual readynesses are unpredictably different. 

For all these 4 cases, 
118 calls at the same time seems overdone. 

In case 3 you could usually spread the calls over time.


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#15816

In article <XnsA0CAA2AF63ACeejj99@194.109.133.133>,
 "Evertjan." <exxjxw.hannivoort@inter.nl.net> wrote:

> Tim Streater wrote on 10 sep 2012 in comp.lang.javascript:
> 
> > Yes, if you only have one that is quite adequate. In my app I have 118 
> > calls to my ajax function.
> 
> If they are triggered by seperate user actions, 
> then it stil is one at a time.
> 
> If there are 118 in one action, that seems not efficient, 
> why not join them to one single Ajax exchange?

There are 118 separate calls as there is a lot to be done at different 
times. I have some 16,000 lines of JavaScript and some 8500 lines of PHP 
in my application.

> When using Ajax, one should always ask onself first,
> what should be acccmplished?
> 
> Meseema there are only 3 reasons:
> 
> 1 the data are not ready when the page loads, 
> and waiting for those data as a regular part of the page 
> is not an option.
> 
> 2 the data depend on user action.
> 
> 3 the data are to be refreshed after a timeout.
> 
> 4 the data are fetched ...

but not from web servers.

> ... from different sources, 
> whose individual readinesses are unpredictably different.

All of the above. These are all calls to localhost as the apache 
instance also runs on the user machine, as this app is in the nature of 
a traditional user application (i.e. can be started by double-clicking 
an icon) rather a traditional website with server on a distant machine. 
I just happen to be using browser + JavaScript + ajax + apache + PHP + 
SQLite as components rather than writing it all in, say, C.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#15828

Tim Streater wrote on 10 sep 2012 in comp.lang.javascript:

>> If there are 118 in one action, that seems not efficient, 
>> why not join them to one single Ajax exchange?
> 
> There are 118 separate calls as there is a lot to be done at different 
> times. I have some 16,000 lines of JavaScript and some 8500 lines of PHP 
> in my application.

So there is only 1 ajax call at a time, so no closures are necessary.

The lines of PHP are off topic, they have nothing to do with the Ajax calls 
in the snese that ajax calles are initiatedd clientside.

"16,000 lines of JavaScript" if this is clientside,
I would say that asks for troubles.



-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#15856

Evertjan wrote:
> Tim Streater wrote:
>
>> There are 118 separate calls as there is a lot to be done at different
>> times. I have some 16,000 lines of JavaScript and some 8500 lines of PHP
>> in my application.
>
> So there is only 1 ajax call at a time, so no closures are necessary.

But still, they're so much fun!  :-)

> The lines of PHP are off topic, they have nothing to do with the Ajax calls
> in the snese that ajax calles are initiatedd clientside.
>
> "16,000 lines of JavaScript" if this is clientside,
> I would say that asks for troubles.

I laugh at your piddling 16,000 lines!  :-)

I'm in the middle of a large application that has, before
concatenation, 70K+ line of Javascript spread over more than 250
files.

Talk about asking for trouble!

  -- Scott

[toc] | [prev] | [next] | [standalone]

#15861

In article 
<8122e8e1-1d1d-4d33-938c-325c4fb7d0e8@y12g2000yqg.googlegroups.com>,
 Scott Sauyet <scott.sauyet@gmail.com> wrote:

> Evertjan wrote:
> > Tim Streater wrote:
> >
> >> There are 118 separate calls as there is a lot to be done at different
> >> times. I have some 16,000 lines of JavaScript and some 8500 lines of PHP
> >> in my application.
> >
> > So there is only 1 ajax call at a time, so no closures are necessary.
> 
> But still, they're so much fun!  :-)
> 
> > The lines of PHP are off topic, they have nothing to do with the Ajax calls
> > in the snese that ajax calles are initiatedd clientside.
> >
> > "16,000 lines of JavaScript" if this is clientside,
> > I would say that asks for troubles.
> 
> I laugh at your piddling 16,000 lines!  :-)
> 
> I'm in the middle of a large application that has, before
> concatenation, 70K+ line of Javascript spread over more than 250
> files.

Hah, I've only got about 30. <sulks>
 
> Talk about asking for trouble!

Well quite.

I may well instrument my ajax function and see if the high-water mark is 
greater than one. I don't see why it wouldn't be.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript

csiph-web