b4rtaz.blog

Na komfort korzystania z serwisu Internetowego wpływa wiele czynników. Niewątpliwie jednym z podstawowych, jest czas jaki musi odczekać użytkownik po kliknięciu w odnośnik do otrzymania odpowiedzi w formie wygenerowanego dokumentu. W dobie gdy bazy danych – podstawy ówczesnych systemów generowania treści, gromadzą kilkaset megabajtów danych, czas w jakim są odnajdowane oraz zwracane rekordy bezwzględnie rośnie.

Na dodatek systemy CMS wysyłają wygenerowany dokument na samym końcu. Tak też jeżeli widzimy w stopce czas generowania strony, to samo wysyłanie zaczyna się dopiero pod koniec pracy skryptu. Nie dość, że użytkownik musi odczekać czas pracy skryptu to jeszcze czas samego pobierania dokumentu. A dlaczego by nie wysyłać stopniowo dokumentu, wraz z postępami pracy skryptu?

Flush idea

Moim celem było stworzenie systemu szablonów który wraz z dostępem do wartości zmiennych wysyłał by stopniowo generowany dokument. Aby to najprościej uzmysłowić, spójrzmy na poniższy szablon:

1. <?xml version="1.0" encoding="UTF-8"?>
2. <user>
3.   <name>{% $name; %}</name>
4.   <age>{% $age; %}</age>
5. </user>

System szablonów o mechanice takiej jak Smarty, po uzupełnieniu wartość zmiennej $name (metodą assign()) nic by nie wykonał dopóki nie została użyta metoda display(). W przypadku Flush'a jest inaczej. Po utworzeniu obiektu klasy (w którym w przeciwieństwie do Smarty należy podać ścieżkę do szablonu),

1. $flush = new flush("./szablon0.htm");

skrypt zaczyna natychmiast wczytywać szablon oraz po kawałku wysyłać go klientowi. Tak długo aż napotka tag którego zmienne nie mają wprowadzonej wartości – w przykładzie jest to $name. W tym momencie proces wczytywania szablonu zostaje przerwany (deskryptory nie zostają zamknięte) i „pole do popisu” dostaje kod dalej.

1. // Jakiś algorytm.
2. $flush->assign("name",$session->get_user_name());

Przy każdym dodaniu zmiennej, skrypt sprawdza czy ostatni tag na którym parsowanie zostało przerwane ma już wszystkie zmienne. Jeżeli tak to proces parsowania szablonu zostaje wznowiony. Jeżeli nie to dalej „czekamy”.

Całkowite generowanie dokumentów

Jeżeli ostatecznie nie dostarczymy zmiennych, to nietrudno się domyślić, że szablon nigdy do końca się nie wygeneruje. Nic bardziej mylnego! Metodą display() na końcu skryptu - jeżeli proces parsowania się jeszcze nie skończył, wygenerujemy resztę szablonu nawet jeśli niektóre tagi nie mają uzupełnionych wartości wszystkich zmiennych (zostaną pominięte bez zatrzymywania).

1. $flush->display();

Gdyby uzupełniono w powyższym szablonie wszystkie zmienne, ów metoda okazała by się niepotrzebna (szablon do końca wygenerowała by ostatnia metoda assign()). Chodź jej stosowanie wypadało by traktować, jako poprawność.

Problemy koncepcyjne

Ze względu na sposób generowania szablonu – który pozwoliłem sobie nazwać strumieniowym, Flush posiada kilka problemów o których należy wspomnieć.

Mechanika parsowania szablonu uniemożliwia tzw. "uzupełnianie wstecz". Tzn. jeżeli parser pominie kilka tagów do określonego fragmentu (kotwice coś takiego umożliwiają – ale zaraz o nich), w późniejszym czasie dodanie wartości do pominiętych tagów, nie spowoduje uzupełnienia ich w już wygenerowanych i wysłanych fragmentach.

Z tego względu uzupełnianie wartości jest procesem bardzo problematycznym - wystarczyło by aby programista zapomniał o uzupełnieniu tagu z początku szablonu, aby cała idea Flush'a poszła na marne. Dokument zaczął by wysyłanie dopiero po metodzie display() która to zapomniany tag by pominęła. Dlatego wpadłem na pomysł... kotwic.

Kotwice

Kotwice pozwalają na skoki do wyznaczonych miejsc, pomijając tagi które nie mają uzupełnionych wszystkich zmiennych (te z uzupełnionymi rzecz jasna zostają wygenerowane). Dla przykładu szablon:

1. <?xml version="1.0" encoding="UTF-8"?>
2. <user>
3.   <name>{% $name; %}</name>
4.   {% hook('hook0'); %}
5.   <age>{% $age; %}</age>
6.   {% hook('hook1'); %}
7.   <city>{% $city; %}</city>
8. </user>

A teraz użycie kotwicy:

1. $flush = new flush("./szablon1.htm");
2.  
3. if($flush->hook(„hook0”)) {
4.  $flush->assign(„age”,$session->get_user_age());
5. }
6.  
7. $flush->display();

Nie ważne, że tag ze zmienną $name nie miał uzupełnionej wartości. Użycie kotwicy – metodą hook(), spowodowało, że nastąpił skok do tagu hook('hook0'); i zwrócenie true na znak sukcesu (znalazłem kotwicę!).

Oczywiście zasada "uzupełniania wstecz" działa także w przypadku kotwic; nie można odwoływać się do kotwic we fragmentach już wygenerowanych i wysłanych. Dla tego parser zapamiętuje jakie już kotwice znalazł, i tak wywołanie metody hook() z nazwą kotwicy która już „przeleciała” zaskutkuje zwróceniem false. Metoda ta zwróci także false jeżeli nie będzie mogła odnaleźć kotwicy – co jest równoznaczne z wygenerowaniem do końca szablonu.

1. $flush = new flush("./szablon1.htm");
2.  
3. // Zwroci true.
4. $flush->hook("hook1");
5.  
6. // Zwroci false (za pozno! już kotwica byla!)
7. $flush->hook("hook0");
8.  
9. // Zwroci false i wygeneruje dokument do konca.
10. $flush->hook("hook-no-exist");
11.  
12. $flush->display();

Kod roboczy

Jako, że projekt jest w fazie koncepcji – i tak naprawdę zadaje sobie pytanie; czy warto go rozwijać, poniżej opublikowany kod roboczy nie powinien być implementowany w żadnym projekcie. Aktualny stan projektu wygląda mniej więcej tak;

• Dostępne wszystkie metody oraz tagi z opisanymi dotąd funkcjonalnościami.
• Nie przedstawione, a funkcjonalne tagi:
  • Instrukcje warunkowe - if(), else, endif (else if nie ma!)
  • Includowanie - include()
• Nie przedstawione, a funkcjonalne metody:
  • Przypisanie kilka zmiennych - assign_array()
• Nie przedstawione, a do zaimplementowania tagi:
  • Wywołania zwrotne – callback()
  • Pętle
• Nie ustalona struktura składni
  • Zwalnianie wartości użytych zmiennych - !$tag

Flush 0.1 Download 13,4 KB

Wydajność

Jeszcze na sam koniec wspomnę o wydajności w porównaniu ze Smarty (w końcu całe wprowadzenie o tym poświęciłem). Szczerze? Nie wiem. Aktualnie projekt jest na takim etapie, że porównywanie wydajności nie ma sensu. Chodź sam fakt, że generowanie dokumentu przejmuje skrypt nie parser PHP ma ogromne znaczenie. Ale gdyby projekt naprawdę zdobył popularność, czy tak trudno było by go przepisać do C i podpiąć bibliotekę? Nie sądzę.