Blog

Budujemy prostą Stronę Na Bazie Express.Js Cz III

Krótki tutorial budowy prostej strony przy pomocy Express.js. Odsłona trzecia.

Budujemy prostą Stronę Na Bazie Express.Js Cz III

Jedną z kluczowych koncepcji MVC jest rozdzielenie logiki “biznesowej”, danych oraz warstwy prezentacji. W aplikacji z tego “klucza” użytkownik zwykle inicjuje żądanie jakiegoś zasobu w serwerze. W efekcie kontroler żąda danych aplikacji z modelu, a następnie przekazuje je do widoku, który ostatecznie formatuje w określony sposób dane dla użytkownika końcowego (w przypadku witryny WWW jest to najczęściej kod HTML). W architekturze MVC widok jest często implementowany za pomocą jednego z różnych języków szablonów. Wygenerowanie kodu HTML za pomocą szablonu pozwala na usunięcie kodu HTML z logiki aplikacji, a tym samym znaczne zwiększenie jego czytelności, ale nie tylko i dzisiejszy wpis -mam nadzieję – będzie tego ilustracją.

Zanim jednak przejdziemy do meritum chciałbym zwrócić uwagę na jedną kwestię, która zapewne nie umknęła osobom, które wykonały dokładnie te same kroki, co autor w poprzednim wpisie. Niestety użyty projekt strony ma jedną dużą niedogodność z punktu widzenia naszego ćwiczenia, ponieważ nie do końca działa jak należy. Wybierając którąkolwiek pozycję w ramach górnej nawigacji zamiast być przeniesionym na wybraną podstronę dostajemy komunikat o błędzie. Jednocześnie jeśli wpiszemy z palca adres, czyli na ten przykład dla  http://localhost:2000/about naszym oczom się objawi właściwy zestaw kolorów i kształtów. 

Zagadka ta wyjaśni się od razu w momencie, gdy zajrzymy do plików html, ponieważ w Navbarze jest odwoła do pełnych nazw plików, czyli dla about będzie to about.html. Żeby temu zaradzić mamy dwie możliwości. Prostsza polega na podmianie nazw tras w naszej aplikacji na zgodne z nazewnictwem użytym w kodzie HTML. Niestety dzieje się to ze szkodą dla elegancji adresów URL prezentowanych użytkownikowi. Dlatego w przypadku estetów pozostaje niestety mozolna edycja każdego pliku z osobna, tak by odwołania odpowiadały docelowym (podanym w pliku aplikacji) trasom. Oczywiście w przypadku tak prostej strony nie stanowi to żadnego problemu, ponieważ mówimy o raptem 4 obiektach do zmiany, ale w przypadku bardziej poważnych projektów kilku studentów znalazłoby czasowe zatrudnienie przy tej zabawie.

Zagadnienie to było już podnoszone przy okazji omawiania komponentów dla frameworka Nuxt.js, gdzie wspominałem, iż w przypadku aplikacji “wielostronicowych” zazwyczaj można w prosty sposób wyróżnić elementy, które się powtarzają niemal zawsze jak choćby wspomniany Navbar. Koncepcja komponentów oraz domyślny wygląd strony był remedium na bolączki z tym związane w przypadku tamtego rozwiązania. Dzięki zastosowaniu języka szablonów, którym się dzisiaj zajmujemy, możemy osiągnąć dokładnie ten sam efekt, czyli w prosty sposób wstrzykiwać w obręb strony pewne powtarzające fragmenty kodu HTML. Jeśli zaś zmodyfikujemy ten kod źródłowy, wówczas zmiany automatycznie będą miały miejsce wszędzie tam, gdzie byśmy tego oczekiwali. 

W naszym wypadku skorzystamy z Handlebars, który oparty jest na popularnym języku szablonów niezależnym od platformy programistycznym, zwanym Mustache. Zanim jednak przejdziemy do ćwiczeń praktycznych dwa słowa wyjaśnienia skąd taki wybór w moim wypadku? Przede wszystkim nie tworzy się tutaj abstrakcji kodu HTML w JS, jak to ma miejsce w być może bardziej poważanych rozwiązaniach. Po prostu piszemy zwykły kod HTML umieszczając w nim specjalne znaczniki, w których Handlebars może umieszczać dynamicznie treść. To jest dokładnie ten sam powód, dla którego odrzucił mnie React z centralną dla niego koncepcją JSX. Poza tym z podobnym podejściem miałem już do czynienia wcześniej w przypadku mojej nieudanej przygody z Django, a co ważniejsze zdaje się, że w przypadku Ghost CMS jest to właśnie mocno wspierana platforma, a właśnie temu rozwiązaniu chciałbym w przyszłości poświęcić więcej uwagi, więc można to traktować jako swoistą przystawkę przed daniem głównym.

A teraz już do rzeczy. Zaczniemy od pewnych zmiana w strukturze katalogu, czyli na początek w katalogu głównym projektu tworzymy folder o nazwie views, a w nim kolejny i opisujemy go jako layouts. Oczywiście nie ma potrzeby kurczowo trzymać się tej nomenklatury, ale akurat tutaj warto pójść zgodnie z duchem tej konwencji, ponieważ Express domyślnie będzie szukał widoków właśnie w tych katalogach, zaś idąc “pod prąd” musimy liczyć się z koniecznością dodania pewnych wpisów koniecznych do konfiguracji. Następnie tych folderach tworzymy pliki zgodnie z widocznym niżej schematem, czyli w katalogu layouts dorzucamy main.handlebars, a schodek wyżej trzy pozostałe.

Wśród korzystających z handlebars popularnym rozszerzeniem plików zawierających widoki jest trzyliterowy skrót hbs. Niestety – uprzedzając fakty – pakiet express-handlebars, który będziemy w naszym projekcie wykorzystywać, oczekuje domyślnie pełnej nazwy, czyli handlebars. Oczywiście można to w dość prosty sposób zmienić dodają przy okazji konfiguracji silnika szablonów dla Express odpowiedni parametr. 

Fotka

Spostrzegawcza osoba zauważy, iż odpowiada to stronom dostępnym w naszym projekcie, choć brakuje jednej z nich, czyli widoku odpowiadającego za URL http://localhost:2000/ contact. Nie jest to przeoczenie, ale celowy zabieg w celu uproszczenia ćwiczenia, ponieważ w przypadku podstrony związanej z kontaktem wykorzystywane są dodatkowe skrypty i trochę to zaburza prostotę budowanego rozwiązania. Następnie otwieramy w edytorze plik main.handlebars i wklejamy do niego zawartość skopiowaną z index.html i w kolejnym kroku usuwamy wszystko co znajduje się między  Navigation a Footer. W to miejsce zaś wstawimy następujący ciąg znaków: {{{body}}}. Dodatkowo od razu usuwamy z nawigacji tę część wpisu, która dotyczy “Contact”.

Fotka

Zanim zabierzemy się za kolejne zmiany w katalogu views dokonanym pewnych modyfikacji zawartości pliku naszej aplikacji. Zacznijmy od importu silnika dla HB, czyli najpierw klepiemy w konsoli npm i express-handlebars. Następnie importujemy ten moduł do naszej aplikacji dodają w górnych partiach pliku index.js (przypominam, że skrypt wykonywany jest od góry do dołu) const expressHandlebars = require(’express-handlebars'). W dalszej kolejności ustawiamy HB jako domyślny silnik dla widoków oraz wskazujemy miejsce (katalog), w którym znajdują się szablony wzorcowe.

app.set(’view engine', 'handlebars')

app.engine(’handlebars', handlebars({

layoutsDir: __dirname + '/views/layouts',

}))

Teraz wystarczy już tylko odrobinę podrasować trasy, pamiętając że strona dla kontaktu wypadła z całości dodając informacje o domyślnym layout. Warto zwrócić uwagę, że nie musimy teraz wskazywać ścieżki do plików, ponieważ – jak wspominałem – Express szuka ich domyślnie w katalogu views oraz views/layouts.

app.get(’/', (req, res) => {

 res.render(’home', {layout : 'main'})

 })

 app.get(’/about', (req, res) => {

 res.render(’about', {layout : 'main'})

 })

 app.get(’/post', (req, res) => {

 res.render(’post', {layout : 'main'})

 })

W tym momencie moglibyśmy ponownie odpalić serwer/aplikację i pod każdym z 3 adresów, coś zobaczymy, choć tylko stopka będzie wyglądała w miarę poprawnie. By uzyskać dokładnie to samo, co na koniec ćwiczenia przedstawionego w ostatnim wpisie, musimy uzupełnić 3 pliki umieszczone bezpośrednio w katalogu views. W każdym z nich wrzucamy to co nie znalazło się w szablonie bazowym. Niżej widać to co zostało dla about.

I to by było tyle na dzisiaj. Obawiam się, że kolejna i tym razem już finalna odsłona tego cyklu zostanie odroczona w czasie, ponieważ w tej chwili próbuję zaprzyjaźnić się z kilkoma innymi tematami m.in. zabawa Pythonem w Minecrafcie oraz przymierzam się powoli do Flaska, któremu pod pewnym względami znacznie bliżej do bohatera niniejszego wpisu niż większego brata, czyli Django. No i może wreszcie czas napisać coś na temat analizy danych.