ciągły update strony bez odświeżania

Witam,
Być może to nierozwiązywalny problem(mi się taki wydaje), byc może to głupie pytanie, ale ze względu na to że ja nie wiem już co robić, to spytam bardziej pro ludzi.
Pytanie brzmi: czy jest możliwe w Rails’ach zrobić coś takiego że lata sobie w tle wątek i np. co jakiś czas update’uje mi konkretnego div’a na konkretnej stronie, bez jej odświeżania. Jeśli da się coś takiego zrobić to prosiłbym o jakiś kod jak to zrobić. Jeszcze pseudokod jakby ktoś nie zrozumiał zagadnienia

view index.html.erb:

controller do niego:
class BlahController<ApplicationController
def index
Thread.new{
while true
#teraz ten psudokod
update_page_with_js_or_sth(‘index’, ‘window’, page[‘window’].zawartosc << “bubub”)
#---------------------------------
sleep 3
end
}
end
end

z góry dzięki

http://api.rubyonrails.org/classes/ActionView/Helpers/PrototypeHelper.html#M001434

Nie mozesz zmusic serwera aby sam komunikowal sie z przegladarka. HTTP tak nie dziala. Klient wysyla zapytanie do serwera, serwer mu odpowiada. Nie da sie odwrotnie. Mozesz wiec tylko ustawic aby klient co powiedzmy minute wysylal jakies zapytanie poprzez XHR i wykonywal skrypt ktory mu serwer zwroci.

class FooController < ApplicationController def periodical_script case(params[:id]) when "alert": render :text => "alert('#{params[:value]}');" when "console.log": render :text => "console.log('#{params[:value]}')" else render :text => "alert('Unkonown action to call')" end end end
Wykonujesz taka akcje poprzez http://api.rubyonrails.org/classes/ActionView/Helpers/PrototypeHelper.html#M001427 i w ten sposob masz to czego cchcesz od drugiej strony.

http://strona/foo/periodical_script/alert?value=dupa wygeneruje skrypt alert(‘dupa’); ktory bedzie mogl byc wykonany przez przegladarke.

Jest coś takiego jak Comet, czy w Railsach “Juggernaut”. Ogólnie rzecz biorąc zasada jest taka, że to serwer inicjuje wysłanie danych do klienta a do komunikacji używany jest niewidoczny aplet Flash. Jeśli nie masz nic przeciwko użuywaniu do tego Flasha (a przy ‘normalnej’ stronie - zazwyczaj powinienes miec cos przeciwko :wink: to mozesz smialo uzyc.

http://juggernaut.rubyforge.org/

Ogólnie to najbardziej przydatne jest do robienia chatów ;).

Jeżeli chodzi o comet, to zagadnienie jest dość złożone i obecnie nie ma chyba implementacji, która rozwiązywałaby wszystkie problemy związane z komunikacją serwer -> przeglądarka.

Krótko o różnych metodach rozwiązania tego problemu:

Polling (nie jest to rozwiązanie typu comet), czyli odpytywanie, to metoda, o której pisze PaK - wysyłanie ajaxowego requesta co kilka sekund. Szczerze mówiąc, nie sądzę, żeby autor wątku potrzebował czegoś bardziej zaawansowanego, nawet campfire używa pollingu i jakoś to działa (o ile jeszcze używają, bo zapewne chcieliby przesiąść się na coś z krótszym czasem odpowiedzi).

Juggernaut jest jednym najbardziej efektywnych z dostępnych rozwiązań, ponieważ wykorzystuje sockety we flashu. Minusem jest oczywiście flash. Wielu ludzi (w tym ja :wink: ) ma domyślnie wyłączonego flasha - niby mogę go włączyć dla strony, która tego używa, ale… jak bym potrzebował czegoś w tym stylu w swojej aplikacji, to bym się dobrze zastanowił nad tym czy użyć flasha.

Long-polling - to jest jedna z technik implementacji serwera push. Wysyłane są długie requesty (na przykład trwające 10 sekund), jeżeli przez 10 sekund serwer nie zwróci odpowiedzi, natychmiast wysyłany zostaje kolejny request. W wypadku kiedy serwer zwróci odpowiedź jest ona od razu odbierana przez przeglądarkę i wysyłany zostaje kolejny request. Dość proste w implementacji, ale ma jedną dużą wadę. Przeglądarka może w danej chwili wykonać tylko 2 requesty do jednego hosta, dlatego jeżeli użytkownik odpali stronę w 2 oknach, to albo trzeba to jakoś wykryć i powiadomić go, że można tego używać tylko w jednym oknie, albo wysyłać odpowiedź od razu, żeby nie trzymać połączenia, co w zasadzie niszczy cały efekt.

No i na końcu cała masa różnych rozwiązań tego problemu typu orbitd, cometd od dojo i ich specyfikacja protokołu bayeux. W dużym uproszczeniu jest to próba implementacji socketów w javascripcie w połączeniu z serwerem push. Minusy są podobne jak w long-polling - ograniczona ilość połączeń i problemy przy proxy chociażby (o różnych problemach z przeglądarkami nie wspominam).

A wszystko to odejdzie w niepamięć jak do użycia wejdzie HTML5, który ma natywną implementację socketów. Tylko na to trzeba będzie jeszcze dłuuugo poczekać :]