Oczywiście bezstanowość HTTP można obchodzić na setki sposobów, tworzyć frameworki, etc tylko że frameworków webowych jest mnóstwo, tak samo języków programowania dla web jest też trochę i trzeba dziesiątek takich frameworków do obchodzenia bezstanowości HTTP.
Wystarczy jeden framework... Nie wiem po co komu dziesiątki framework'ów... Wybieram jeden, on obchodzi wszystko za mnie i nie mam takich problemów.
Ja dla przykładu w robocie muszę używać i w tym czymś sesja chyba wygasa po 30 czy 15 (sam nie wiem) minutach.
Należy ustawić czas sesji dostosowany do aplikacji. Jeżeli masz duuuże formularze, to chyba logiczne, że użytkownikowi długo zajmie ich wypełnienie. Należy umożliwić użytkownikowi zapisanie danych w międzyczasie i wrócenie do nich później (jak to robią strony umożliwiające wypełnienie pita online).
Nawet pingowanie jest kiepskim rozwiązaniem bo ktoś może mieć chwilowe problemy z siecią, a jeśli ma 10 kart otwartych to pingowanie jest razy 10.
A co ty chcesz osiągnąć pingując? XD XD XD Dobra, Wibowit, trzymaj się od web aplikacji z daleka lepiej, hm? W której warstwie jest ping, a w której sesja?
trzeba wstawiać jakiś tymczasowy stan do sesji, no chyba, że używamy AJAXa, ale wtedy utrudnione jest zachowywanie explicite częściowych danych z formularza na później
Co? A w jaki sposób utrudnione jest przechowanie danych, kiedy używasz AJAXa? Chyba masz nieprzemyślaną strukturę przechowującą dane formularza. Nie zwalaj winy za swój brak umiejętności na protokół.
Z bezstanowością HTTP związane są jeszcze inne problemy, np nie da się zalogować do jednego serwisu jako dwóch lub więcej użytkowników naraz, trzeba stosować jakieś hacki, dla przykładu weźmy dwa konta mail na tym samym serwerze.
Wystarczy odpalić drugą przeglądarkę... Poza tym, gdybym chciała by moja aplikacja umożliwiała multilogowanie, to też jestem w stanie to zaimplementować. Większość aplikacji (również desktopowych) nie udostępnia takiej funkcji, ponieważ twórca aplikacji jej nie przewidział. Pretensje proszę do twórcy, nie do protokołu.
@Wibowicie, widzisz mnóstwo problemów, których nie ma, albo wynikają ze złej architektury aplikacji. Nie jest winą http to, że ty musisz w pracy wypełniać 10 stronicowe formularze, które nie obsługują sesji, czy wygasają ci za szybko. To jest wina twórcy tej aplikacji.
Poza tym narzekanie na bezstanowość http, to jak narzekanie na brak obiektowości w C. No bo czemu ja muszę stosować różne myki i hacki, żeby udawać obiekty w C? Odpowiedź jest bardzo prosta, trzeba wiedzieć co jest do czego, i wykorzystywać narzędzia adekwatne do tego, co próbujemy osiągnąć. Do tego nie należy się brać za implementowanie 10 stronicowych formularzy, jak się nie wie nawet, w której warstwie jest sesja.
