Formularze Yesod ze strumieniem strony

Question

Niektóre formularze są zbyt skomplikowane, aby zmieściły się na jednej stronie. Jeśli na przykład formularz zawiera duże ilości uporządkowanych danych, takich jak wybieranie lokalizacji na mapie, planowanie wydarzeń w widżecie kalendarza lub zmiana niektórych części formularza w zależności od wcześniejszych danych wejściowych, warto mieć możliwość rozbić pewną formę na wiele stron.

Jest to łatwe do zrobienia dzięki dynamicznym stronom internetowym i skryptom JavaScript, ponieważ wystarczy utworzyć widżet karty z różnymi stronami, a faktyczny przesłany formularz będzie zawierał cały widget karty i wszystkie jego pola wejściowe, generując pojedyncze: POST wniosek o całą operację.

Czasami jednak generowanie pewnych pól wejściowych zajmuje dużo czasu; mogą nawet być intensywne obliczeniowo nawet po wygenerowaniu strony, obciążając przeglądarkę użytkownika komputera niższego rzędu. Dodatkowo staje się trudne lub niemożliwe tworzenie formularzy, które dostosowują się do wcześniejszych danych wejściowych.

Dlatego konieczne jest podzielenie określonego formularza na wiele pełnych żądań stron.

ten może okazać się trudne, zwłaszcza, że ​​na pierwszej stronie formularza POST do /location/a, który wystawi przekierowanie do /location/b i zażądał jako GET przez klienta. Przekazywanie przechowywanych danych formularzy z POST /location/a do GET /location/b jest tam, gdzie leży trudność.

Erwin Vervaet, twórca Spring Web Flow (podprojekt wiosennej struktury, znany głównie ze swoich możliwości wtłaczania zależności), raz napisał a blog article demonstrując tę ​​funkcjonalność we wspomnianym frameworku, a także porównując go z Lift Web Framework, który zaimplementował similar functionality. Następnie przedstawia wyzwanie dla innych frameworków internetowych, które są dalej opisane w a later article.

Jak Yesod zmierzyłby się z tym problemem, zwłaszcza biorąc pod uwagę jego bezpaństwowy charakter oparty na REST?

Answer 1

Po pierwsze, nie istnieje jeszcze gotowe rozwiązanie tego problemu (przynajmniej o tym wiem). I nie wiem, w jaki sposób inne wspomniane frameworki rozwiązują problem. Więc to, co tu mówię, jest dość przypuszczające. Jestem jednak prawie pewien, że to zadziała.

Istotą problemu jest kodowanie parametrów POST strony A do żądania GET dla strony B. Najprostszym sposobem na to byłoby przyklejenie parametrów POST strony A do zmiennej sesji. Jednak spowoduje to dość poważne zerwanie nawigacji: wstecz/do przodu w ogóle nie będzie działało zgodnie z opisem.

Powróciliśmy więc do REST: musimy zakodować parametry POST w samym żądaniu. To naprawdę oznacza umieszczenie informacji w żądanej ścieżce lub ciągu zapytania. A ciąg zapytania prawdopodobnie ma największy sens.

Byłbym zaniepokojony umieszczeniem surowych parametrów POST w ciągu zapytania, ponieważ pozwoliłoby to serwerowi proxy łatwo odczytać zawartość. Chciałbym wykorzystać istniejącą kryptografię z sesji klienckiej. Innymi słowy, przykleimy podpisaną, zaszyfrowaną wersję poprzedniego formularza w parametrze ciągu zapytania.

Aby uczynić go nieco bardziej konkretne:

• użytkownik przechodzi do strony A poprzez GET.
• Użytkownik wysyła stronę A za pośrednictwem POST.
• Serwer sprawdza poprawność przesłania formularza, pobiera wartość, serializuje go, szyfruje/haszy.
• Użytkownik jest przekierowywany do strony B jako GET, z parametrem ciągu zapytania zawierającego zaszyfrowaną/zakodowaną wartość ze strony A.
• Kontynuuj ten proces tyle razy, ile potrzeba.
• Na ostatniej stronie możliwe jest odszyfrowanie parametru ciągu zapytania i przesłanie wszystkich formularzy.

Wygląda na to, że byłoby fajnym dodatkiem do pakietu, jeśli ktoś jest zainteresowany.