2015-05-28 14 views
7

Jaki jest akceptowany sposób synchronizowania danych aplikacji internetowej z serwerem, gdy użytkownik zamyka okno przeglądarki bez uprzedniego zapisania pracy? Mówię albo uderzając "X", albo nawet naciskając F5 lub coś podobnego.Jak zapisać stan strony podczas zamknięcia

Trochę tła:

webapp w pytaniu jest okno główne, a następnie okna potomne, które pojawiaja sie co jakis głównego okna, umożliwiając piaskownicy „praca” do zrobienia w oknach potomnych. Nie mam kontroli nad tym aspektem wdrożenia.

Przypadek użycia:

Każde okno dziecko może mieć dość sporą ilość informacji wprowadzonej zanim użytkownik zdecyduje się kliknąć „OK”, aby utrzymywać dane na serwerze.

Czego już uważane/próbowałem:

  • Proste bliską potwierdzenie powrocie ciąg z obsługi onbeforeunload zdarzeń, jeżeli jest niezapisana praca. (problem: moja prowadzić zespół nie chce ruszyć na umożliwienie „alert okno” przeglądarki specyficzne być w webapp Według niego. Doświadczenie użytkownika wychodzi okno opierając się na tym brzydkim oknie patrząc.)
  • AJAX żądanie zwolnione podczas zdarzenia onpageunload, które wysyła dane z powrotem do serwera. (problem: ponieważ zwrotna XHR nigdy nie jest wywoływana, znajdę jakieś przeglądarek pozostawiając otwarte połączenie, a następnie losowo próbujących odpalić zwrotnego przyszłego oknie, które zostanie otwarte.)
  • Synchronous AJAX wniosek zwolniony podczas onpageunload wydarzenie. (problem: Ignorowanie faktu, że ludzie, w tym ja sam, nienawidzę robienia tego oraz faktu, że jest on nieaktualny i zostanie usunięty w przyszłości ... Interfejs użytkownika może potencjalnie zawiesić się na długi czas oczekiwania na żądanie AJAX do kompletne, może w nieskończoność, jeśli utracą połączenie z Internetem.)
  • Zapisywanie zawartości strony w regularnych odstępach czasu lub poprzez dołączanie obsługi zdarzeń onchange/onblur/onwhateverelse. :
  • Korzystanie localStorage zachować zmienione pola na maszynie klienta aż faktycznie popełnić swoje prace do serwera (problem ogromne ilości kodowania napowietrznych w porównaniu do bardziej „leniwe” wdrożeń powyżej i poniżej.). (problem: obsługa przeglądarki ... to musi obsługiwać tyle miejsc, co obsługa XHR.) Czy pamięć po stronie klienta ma tak szerokie wsparcie? Myślę, że jest trochę luki, jeśli się nie mylę.)

Z góry dziękuję za dane wejściowe.

+1

"Doświadczenie użytkownika wychodzi przez okno polegające na tym paskudnie wyglądającym oknie dialogowym." Widzę, że był używany na Facebooku, Gmailu i gdzie indziej. Podejrzewam, że wykonali bardziej obszerne testy doświadczenia użytkownika niż prowadzący. – ceejayoz

+0

Uzgodnione. Niestety ta osoba ma dużo ciągnięcia i niestety, nie mogę skorzystać z opcji 1 :( – Harvtronix

+1

Ponieważ opcje 2, 3 i 5 mogą potencjalnie włamać się do co najmniej niektórych przeglądarek, spraw, by twój zespół wybrał między opcjami 1 i 4. mogą poświęcić czas i pieniądze na zrobienie czegoś, co wymaga więcej wysiłku, aby utrzymać konserwację, lub mogą wybrać proste, "brzydkie" rozwiązanie, które będzie znane użytkownikom końcowym: – BSMP

Odpowiedz

2

Rozwiązanie, które wymyśliłem, jest zasadniczo zmodyfikowaną wersją wyboru 4 z góry.

Opracowałem pewną logikę, która rejestruje funkcje obsługi zdarzeń onchange/onkeypress z węzłami zidentyfikowanymi przez pewien atrybut (w tym przypadku data-save-state="true") po załadowaniu strony.

Aby tego dokonać, jedynym wymaganiem dla programistów każdego z "okien podrzędnych", które są uruchamiane z głównego okna, jest zarejestrowanie identyfikatora URI, do którego mają zapisywać swoje dane za pomocą mojego nowego modułu javascript Saver.

Zidentyfikowane wartości elementu są serializowane i wysyłane jako obiekt JSON do Saver. Saver jest odpowiedzialny za ustawianie w kolejce zestawów żądań i wysyłanie ich do serwera jako grupy, gdy nie wykryto żadnych dalszych zmian przez 1000 ms.

To było dla mnie większe obciążenie, które musiało rozwinąć umiejętność robienia tego, ale teraz, gdy tam jest, jest całkiem proste dla innych członków zespołu, aby zintegrować się z ich kodem.

Jeśli chodzi o ryzyko utraty danych, jedynym ryzykiem jest teraz tyle czasu, zanim żądanie zapisu zostanie wysłane na serwer. To rozwiązanie wydaje mi się bardzo "Dokumentami Google".

+0

Ach, to interesujący sposób na rozwiązanie problemu! :) – towerofnix

1

Brzmi tak, jakbyś chciał używać plików cookie. O ile mi wiadomo, jest obsługiwany przez praktycznie każdą przeglądarkę internetową.

Jedyną rzeczą, na którą localStorage nie jest obsługiwana, jest Opera Mini. Myślę, że to trochę za dużo nieobsługiwania dla ciebie lub dla osoby, dla której program jest tworzony.

Here's a plugin for handling cookies, ponieważ one naprawdę nie są czymś, z czym chcesz sobie poradzić bez wtyczek. ;) Wygląda na to, że jest obsługiwany w dowolnej przeglądarce!

Jeśli nie chcesz korzystać z biblioteki, oto strona Mozilla Developer Network pod adresem Document.cookie.

Jeśli chcesz przeczytać o historii plików cookie, możesz sprawdzić this.

+0

Należy jednak pamiętać o ograniczeniach rozmiaru/długości plików cookie, które mogą się również różnić w zależności od przeglądarki - należy o tym pamiętać, ponieważ autor twierdzi, że może to być współ znaczna ilość danych. – jjczopek

+0

@jjopopek Tak, dokładnie. Mówimy o potencjalnie dużych (setkach pól formularzy naraz) ilości informacji. Niestety użycie pliku cookie do przechowywania tych danych nie byłoby możliwe. – Harvtronix

Powiązane problemy