Blog >
Aplikacje internetowe często polegają na przechowywaniu i przetwarzaniu danych wprowadzanych za pośrednictwem formularzy. Są one zwykle używane w predefiniowanych scenariuszach, w których aplikacja zaplecza oczekuje określonych danych z określonych żądań API. Predefiniowane formularze spełniają potrzeby większości przypadków użycia, ponieważ struktura danych, taka jak modele baz danych, nie zmienia się w locie.
Trees4Travel współpracuje z markami turystycznymi na całym świecie w sektorze biznesowym i rekreacyjnym w celu zapewnienia technologii zarządzania emisjami dwutlenku węgla. Systemy firmy pomagają obliczać i redukować wpływ emisji. Trees4Travel ułatwia pozytywny wpływ na klimat poprzez bezpośrednią integrację z systemami rezerwacji, łączność API lub prosty transfer plików. Firma edukuje podróżnych i zapewnia niezbędne narzędzia przejściowe, aby przenieść nas z miejsca, w którym jesteśmy dzisiaj, do przyszłości - czyniąc podróże i wydarzenia bardziej etycznymi i zrównoważonymi.
Co jednak, gdyby zaistniała potrzeba przetwarzania danych, których struktury nie można przewidzieć i które są zbyt złożone, by przechowywać je w postaci prostej listy klucz-wartość? Z takim problemem spotkał się system Trees4Travel. Załóżmy system marketingowy z listą kontaktów i szablonami wiadomości e-mail. Celem jest zdefiniowanie treści wiadomości e-mail i listy odbiorców, którzy mają ją otrzymać.
Szablony wiadomości e-mail używają Handlebars - języka szablonów używanego do definiowania sposobu, w jaki szablon powinien analizować dane wejściowe na wiadomość wyjściową. Najczęściej polega to na definiowaniu zmiennych w formacie "wąsów", takich jak "Drogi {{firstName}}". Istnieją jednak bardziej zaawansowane funkcje, takie jak zawartość warunkowa, pętle nad tablicami, zmienne formatujące, a nawet niestandardowe parsery zdefiniowane przez użytkownika. W rezultacie każdy szablon wiadomości e-mail będzie miał swój unikalny zestaw parametrów wejściowych, często składający się z tablic i zagnieżdżonych obiektów.
Teraz wracamy do naszego problemu - musimy wypełnić treść takich szablonów wiadomości e-mail, przechowywać je w systemie i wysyłać (okresowo) do wybranych kontaktów. Jak możemy to osiągnąć?
Zamiast wymyślać koło na nowo, możemy skorzystać z pomocy zewnętrznych pakietów i modułów. W tym przykładzie przyjrzymy się narzędziu javascript o nazwie JSONEditor. Założenie jest proste: Użytkownik dostarcza schemat json, który definiuje strukturę formularza i dane wejściowe/wyjściowe. Narzędzie to zapewnia wszystkie funkcje potrzebne do zdefiniowania naszego formularza: Pola tekstowe, listy rozwijane, pola warunkowe, tablice, pola zagnieżdżone, wsparcie dla edytorów tekstu sformatowanego, przesyłanie plików i tak dalej. Poniższy diagram pokazuje, jak to działa.
Inicjalizacja JSONEditor wewnątrz elementu div jest naprawdę prosta, jak pokazano poniżej. Wśród różnych pól konfiguracyjnych możemy wybrać motyw CSS spośród kilku istniejących lub możemy użyć motywu barebones i ręcznie stylizować wygląd formularza.
Teraz musimy po prostu dostarczyć schemat JSON dla każdego szablonu wiadomości e-mail, aby zdefiniować każde edytowalne pole, a następnie użyć dynamicznie generowanego formularza do wypełnienia danych, zapisać wynik w formacie JSON (abyśmy mogli zapisać go w bazie danych w celu późniejszego wykorzystania lub edycji), a następnie użyć Handlebars do wypełnienia szablonu wiadomości e-mail wartościami naszego formularza. Jak to wygląda w praktyce? Spójrzmy na przykład z systemu marketingowego Trees4Travel.
Po pierwsze, nasz system ładuje listę szablonów e-mail bezpośrednio z SendGrid, co oznacza, że w dowolnym momencie możemy edytować te szablony i natychmiast aktualizować je w systemie.
Po dokonaniu wyboru przyjrzyjmy się surowemu szablonowi. Jest to prosty przykład, ale możemy zobaczyć kilka zmiennych kierownicy, takich jak {{firstName}} i {{buttonText}}.
Napiszmy schemat, aby wygenerować formularz do edycji tego szablonu. Możemy to zrobić bezpośrednio w systemie, który zapisuje schemat w bazie danych.
Ten schemat definiuje formularz, który wygeneruje wynik JSON używany do wypełnienia treści naszej marketingowej wiadomości e-mail. Każde pole ma nazwę, typ i opcjonalnie tytuł i format. Tutaj używamy 3 typów pól: Proste pole tekstowe, pole tekstowe "xhtml", które będzie wyświetlane jako edytor tekstu sformatowanego w formularzu, oraz pole boolean true/false.
Wreszcie, oto działający przykład formularza z podglądem na żywo, jak będzie wyglądać wiadomość e-mail po przeanalizowaniu.
Nasz system idzie o krok dalej i wykrywa niektóre zmienne, takie jak imię i zastępuje je imieniem rzeczywistego odbiorcy. Możemy wysłać tę wiadomość e-mail do wielu kontaktów jednocześnie, a każdy z nich będzie miał własne imię.
Używamy również podobnego systemu do definiowania zawartości spersonalizowanej strony lasu. Przyjrzyjmy się przykładowi, który generuje bardziej interesujący formularz, który definiuje tablicę, w której każdy wpis jest miesięczną aktualizacją zalesiania składającą się z: przedziału czasowego, wpisu tekstowego, zdjęcia i opcjonalnie wideo.
Po pierwsze, schemat:
Tutaj mamy prosty tekst nagłówka i typ tablicy. Pole "items" definiuje format każdego wpisu tablicy. Wewnątrz zagnieżdżone są pola dla każdego wpisu. Interesujące jest z pewnością pole zdjęcia, ponieważ wykorzystuje ono kontrolkę przesyłania plików. Aby to zadziałało, musimy wcześniej skonfigurować kilka rzeczy. Po pierwsze, widać, że używamy "upload_handler". Musimy zdefiniować sposób, w jaki faktycznie przesyła plik:
Powyższy kod definiuje nasz "defaultUploadHandler", który wykorzystuje FileReader do odczytu zawartości pliku w formacie Base64, a następnie wykorzystuje żądanie post do wysłania pliku na nasz serwer:
To, jak dokładnie plik jest przechowywany na serwerze, zależy od implementacji, ale zdecydowaliśmy się przechowywać je w usłudze Azure Blob Storage. Powyższe żądanie zwraca adres url z naszego API wskazujący na nowo zapisany plik, który jest następnie przekazywany z powrotem do naszego formularza. Jest to ważne, ponieważ oznacza to, że nigdy nie przechowujemy całego pliku w wyniku JSON formularza - zamiast tego zapisujemy tylko wynikowy adres URL do miejsca, w którym plik jest przechowywany w naszym magazynie obiektów blob.
Po pierwsze, możemy zobaczyć kontrolkę przesyłania plików, która działa dokładnie tak, jak byśmy tego oczekiwali - wybieramy plik, przesyłamy go i to wszystko - wynikowy adres URL obrazu jest już przechowywany w formularzu.
Możemy również zobaczyć zarządzanie tablicą w akcji. W lewej kolumnie widzimy listę wpisów. Za pomocą przycisków na górze i na dole możemy dodawać, usuwać, zmieniać nazwy i kolejność wpisów w dowolny sposób - jest to bardzo elastyczne. Aby faktycznie iterować po wynikowej tablicy JSON, musimy użyć słowa kluczowego #each w handlebars.
Dzięki temu możemy łatwo aktualizować naszą stronę zalesiania
Podsumowując, zobaczmy, w jaki sposób dynamiczne formularze, a konkretnie JSONEditor, mogą pomóc nam w pracy, ale także kiedy nie zaleca się ich używania. Zalet jest oczywiście wiele. Dzięki temu narzędziu i sposobowi w jaki zostało ono zaimplementowane w systemie możemy:
Należy jednak zauważyć, że wyniki JSON, choć łatwe do przechowywania w bazie danych i używania w tym edytorze, są raczej trudne do pracy poza tymi przypadkami użycia do ręcznych modyfikacji. I chociaż narzędzie to jest dość elastyczne pod względem tego, co możemy osiągnąć, używanie go wyłącznie w celu pisania aktualizacji w stylu postów na blogu, gdzie każdy z nich wykorzystuje ten sam układ formularza, prawie na pewno byłoby uważane za przerost stylu nad treścią, zwłaszcza gdy większość systemów CMS okazałaby się znacznie lepsza do tego zadania.
To powiedziawszy, powyższy przykład e-maili marketingowych jest idealnym kandydatem do tego narzędzia, ponieważ opiera się w dużej mierze na częstej edycji formularzy, potrzebie natychmiastowego zobaczenia wyników, elastyczności danych wejściowych / wyjściowych i możliwości przechowywania wyników w formacie JSON w bazie danych w celu skonfigurowania cyklicznych treści marketingowych.
