2009/2/28 Tobie Langel <tobie.lan...@gmail.com>:
>
> TJ, I think BearState is just missing the async nature of ajax.
>
> Best,
>
> Tobie
>
> On Feb 27, 11:17 pm, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
>> Hi,
>>
>> > No, the only real solution here, is to split the module at the point
>> > of the Ajax.Request() call...Then,  call the
>> > remainder wrapped in a setTimeout().
>>
>> Why not in the onSuccess of the Ajax.Request?  That's what it's there
>> for...  You'll never get the timing right 100% of the time with
>> setTimeout.
>> --
>> --
>> T.J. Crowder
>> tj / crowder software / com
>> Independent Software Engineer, consulting services available
>>
>> On Feb 27, 5:30 pm, BearState <wixelb...@yahoo.com> wrote:
>>
>>
>>
>> > Thanks for the feedback,
>>
>> > I appreciate it.    True, it would be nice to have a progress
>> > indicator.  But I also said that the delay was not long, but long
>> > enough to be of consequence.  Therefore, the progress indicator is not
>> > an issue.
>>
>> > The issue is that the code is a modular response to a user click for
>> > some web page functionality and the code module runs on with
>> > processing w/o the data it needs to do the processing.
>>
>> > I found it funny that calling the Ajax.Request() twice in a row
>> > provided just the right length of delay to get it right, but ...
>> > that's a bandaid and sucks.
>>
>> > No, the only real solution here, is to split the module at the point
>> > of the Ajax.Request() call  ( and it is a separate function - yes )
>> > and create another module of the remainder.   Then,  call the
>> > remainder wrapped in a setTimeout(). That actually works fine and
>> > gives the required delay and further, control over how long the delay
>> > should be ... with capability for handling the exception of not
>> > getting the data from the call.
>>
>> > It seems a bit klugey to me to do it that way, but it's not the first
>> > time I've seen how Javascript and HTML can be klugey.
>>
>> > I said that some people might consider it a bug, because I'd seen
>> > posts on the web that decried 'Problems with Ajax'  that likely are
>> > tied to not understanding that there is a delay involved in getting
>> > stuff back from the server.
>>
>> > It is BTW and IMHO  appropriate for the Request to allow the code to
>> > ramble on. All you have to do is consider a Web 2.0 that starts
>> > several requests while loading to understand how important it is to
>> > give the user something to do on the page while that stuff is
>> > background loading ... then, perhaps, make it visible.  Who needs a
>> > progress indicator,when you don't even have to make the loaded data
>> > visible until you have it?   No data?  --  No Errors and just the page
>> > missing whatever it was.   Wouldn't it be dumb to show a progress bar
>> > and then get no data?
>>
>> > Anyhow,  I've found a solution and will progress from that.
>>
>> > Thanks again.
>>
>> > BearState
>>
>> > On Feb 27, 7:31 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
>>
>> > > > T.J., while I absolutely agree with what you have said, I think you're
>> > > > missing part of BearState's question:
>>
>> > > Thanks, Colin.  On first read, I thought he meant some knucklehead
>> > > *programmers* might think it was a bug *in Prototype*.  But I think
>> > > you're right.
>>
>> > > And yes, simply displaying something when there's an outstanding
>> > > request should provide the appropriate feedback.  In fact, the
>> > > Ajax.Responders[1] are designed specifically for doing this (amongst
>> > > other things), and they even maintain a handy "how many requests are
>> > > pending" counter (Ajax.activeRequestCount) for you...
>>
>> > > [1]http://prototypejs.org/api/ajax/responders
>>
>> > > FWIW,
>> > > --
>> > > T.J. Crowder
>> > > tj / crowder software / com
>> > > Independent Software Engineer, consulting services available
>>
>> > > On Feb 27, 2:57 pm, ColinFine <colin.f...@pace.com> wrote:
>>
>> > > > On Feb 27, 6:21 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:> 
>> > > > Hi,
>>
>> > > > > Rather than thinking of an Ajax request as a function call, think of
>> > > > > it as a message you send out.  Send it, then get on with other 
>> > > > > things,
>> > > > > or just wait (where waiting is not a busy-wait where the user can't 
>> > > > > do
>> > > > > anything).  When you get a reply, deal with the reply.  In this case,
>> > > > > replies are (basically) "complete" and "failure".
>>
>> > > > T.J., while I absolutely agree with what you have said, I think you're
>> > > > missing part of BearState's question:
>> > > > "Some knuckleheads might well be provoked to say, "Hey, I didn't get
>> > > > my
>> > > > data.  There's a bug." "
>>
>> > > > The trick then is to make something happen visually to show the user
>> > > > that something is happening: an animated cursor, an hourglass, even
>> > > > just temporarily change the colour of something.
>>
>> > > > Some Scriptaculous facilities provide this for you (see 'indicator' 
>> > > > inhttp://wiki.github.com/madrobby/scriptaculous/ajax-autocompleter, for
>> > > > example, but I think you'll have to do it yourself with the basic
>> > > > Prototype Ajax classes. But it's not hard. You set something in the
>> > > > 'onCreate' callback, and remove or stop it in 'onComplete'.
>>
>> > > > Colin- Hide quoted text -
>>
>> > > - Show quoted text -
> >
>

BearState,

Creating an Ajax request is only the creation of the request. It does
not wait until there is a response before giving you control back to
you.

e.g.

result1 = func1();
result2 = func2();
result3 = func3();

As each function is called,the results are returned and code carries
on to the next line.

Ajax calls don't work the same way. The call to make the request
returns as soon as it can after the request has been made. And your
code carries on running.

Sometime later, a response comes in. Or not. Depending upon the speed
of their connection, the lag times and the server response times, etc.
A LONG delay in computer time. And sometimes a long delay in people
time.

Processing of the request is "out of step" with the normal flow of
your code. This is normal and you have to deal with it. The easiest
way is to put the processing of the response in the onSuccess callback
of the request.

It does mean that if you have code further down the list of things to
do which is reliant on the result of the request, then it will have to
wait as well.

So, that code would have to be part of the onSuccess too.

Hope this is understandable.

Regards,

Richard.

-- 
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to