On 10 avr, 11:26, "cirpo" <[EMAIL PROTECTED]> wrote:
> hi, i can't figure out how to solve this problem:
> i do a an ajax.updater, it works but i would like that the message
> returned by the server "lives" only for 5-10 seconds and then
> disappears.(like in Gmail, when you send/delete/etc a message a new
> line appears for few second and then it disappears).
>
> this is my function:
> function addgr(){
>                 var gr=$F('form');
>                 var url= 'page.php';
>                 var par = 'add=' + gr ;
>                 var target = $('msg');//the meassage that has to appear for 
> 5-7
> seconds
>                 var addingr = new Ajax.Updater(target,url,{method:
> 'get',parameters : par});
>                 }
>
> thanks.
>
> cirpo

What you are trying to do is more a problem of server response, you
shouldn't make the client take care of how long a response should
last. The server should be responsible of that task since that it is
it who is responsable of the control flow in your app/Web page. I had
to implement a similar system in my app, and since Prototype is a nice
framework, he will handle whatever the server ask it to do
automatically. Consider this :

var options = {
  method: 'get',
  parameters: par,
  requestHeaders: ['object', 'TestUpdater'],   // optional...
  evalScripts: true    // execute any embedded scripts in the response
};

new Ajax.Updater( 'msg', 'page.php', options );


And a typical response would be :

<div id="msg3434323466792">
<b>Response is : </b>Hello world !
<script type="text/javascript">
  setTimeout( function() { Element.remove('msg3434323466792'); }, 5 *
60 * 1000 );
</script>
</div>


Since we did set 'evalScripts' to 'true', any <script> tag found will
be removed and executed. The response should have, then, a tag with a
very unique Id (usually composed from a timestamp) and the script
executed by the update method of prototype creates a timer that will
remove that tag later on.

This way, you decouple your client from the responsibility of
"cleaning up" the server responses. After all, it doesn't matter from
who, when, or where the request originated ; the client should only
ask question, and handle events, not control the behavior of the
interface.

Hope this helps.

-Yanick


--~--~---------~--~----~------------~-------~--~----~
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 [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to