zastosowania haxe głównie dla programistów PHP a w szczególności Drupala

Transkrypt

1 Opracował Grzegorz Nowak strona domowa: mail: zastosowania haxe głównie dla programistów PHP a w szczególności Drupala

2 Spis treści Wstęp...3 O autorze...3 Dla zainteresowanych...3 Słowem wytłumaczenia...3 Co to jest haxe?...4 Komu potrzebna ta, dodatkowa, technologia?...4 Ogólne Korzyści z korzystania z abstrakcyjnego języka obiektowo zorientowanego...5 Analiza wydajności działania aplikacji...6 Target PHP: wbudowany mechanizm automatycznego ładowania klas...7 Podsumowanie...8 Analiza szybkości projektowania, łatwości implementacji i czytelności kodu...9 Zastosowanie frameworka PureMVC...9 O czytelności jeszcze słów kilka...11 Przenośność i możliwość ponownego użycia kodu...13 Znana historia...13 A co z oczywistymi różnicami między technologiami?...13 haxe versus Java...13 Integracja haxe'a z Drupalem...15 Platforma developerska...16 Co jest potrzebne do łatwego tworzenia kodu haxe...17 Konfiguracja Workspace'a...18 Setup dla haxe (program FlashDevelop)...18 Setup dla Drupala (Eclipse)...19 Przykładowe aplikacje...23 Przykład modułu...24 Zaczynamy...24 Po stronie PHP (środowisko Eclipse)...24 Po stronie haxe (środowisko FlashDevelop)...26 Integracja z Drupalem (hooki, itp.)...30 Eksport kodu...31 Kompilacja...31 Eksport właściwy...34 Czy to w ogóle działa?...38 Podsumowanie...39

3 Wstęp O autorze Grzegorz Nowak jest projektantem i programistą aplikacji na platformy Drupal/Flash/AIR. Para się Drupal Consultingiem. Współtworzy agencję interaktywną Altart Intermedia ( zajmującą się,m. in. profesjonalnymi wdrożeniami systemów CMS różnych typów i wielkości opartych o platformę Drupal CMS. Jeśli szukasz firmy z bogatym doświadczeniem w pracy z Drupalem i z rozległą wiedzą z zakresu technologii internetowych, to zapraszam do współpracy z firmą Altart. Jeśli potrzebujesz do projektu osoby z pasją do programowania, znajomością nowoczesnych technik projektowania aplikacji i z brakiem oporu przed nowym i nieznanym, to polecam swoją osobę. W każdym z powyższych zapraszam do kontaktu mailowego: g.nowak@altart.pl Profil GoldenLine: Dla zainteresowanych Propozycje poprawek, uwagi, listy błędów merytorycznych, składniowych i literówek, sugerowane zmiany i rozwinięcia tematu proszę słać na adres g.nowak@altart.pl. Zachęcam również wszystkich do dodawania gotowych rozdziałów, tłumaczenia całości, lub fragmentu na inne języki i, ogólnie, wpłynięcia na kształt tego opracowania. Nie łudzę się, że przebiję popularnością choćby pierwszą lepszą książkę kucharską, ale już choćby garstka ludzi ciągnących zagadnienie może, w widoczny sposób zwiększyć stopień adopcji danej technologii. Słowem wytłumaczenia Jakże krytyczni i bezduszni pod przykryciem płaszczyka anonimowości nieraz potrafią być moi krajanie przekonałem się nie raz. Tworząc przez długi czas zespół muzyczny, nagrywający, dystrybuujący i koncertujący, wyrobiłem sobie zdolność ignorowania bezpodstawnych zarzutów, kalumnii i, po prostu, przejawów czystej, polskiej zazdrości. Osobiście niespecjalnie mnie takie zachowanie rusza. Jednocześnie bardzo cenię zdanie osób mających bogatą wiedzę ( zwłaszcza popartą doświadczeniem ) i jestem szczerze otwarty na sensowną polemikę i chętnie wysłucham

4 konstruktywnych argumentów za, lub przeciw moim poglądom, a także wytknięcia zwykłych pomyłek. Byle sensownie, proszę. Pisząc ten przewodnik korzystałem z kilkudniowego urlopowego odpoczynku od codziennych obowiązków. W wielu miejscach brak czasu nie pozwolił mi zagłębić się w szczegóły działania pewnych mechanizmów, a otwarty charakter ( zarówno mój jak i tego materiału ) sprawił, że nieraz odpłynąłem od tematu, albo zacząłem czyste spekulacje i nieuzasadnione przepowiednie. Mimo iż wirtualny świat komputerów, jest moją pasją, to sam sceptycznie podchodzę do tych rozmarzonych fragmentów. No ale cóż, słowo się napisało, więc już niech zostanie. Starałem się, na przestrzeni tych kilkudziesięciu stron, przedstawić zarys idei na jeszcze łatwiejsze i szybsze tworzenie przenośnych rozwiązań z wykorzystaniem języka haxe. I znów z pewnych przyczyn, umieściłem jedynie minimum kodu, mogące służyć wyjaśnieniom, a nie całe, gotowe rozwiązania. W pracy korzystam co prawda ze sporych, ręcznie napisanych bibliotek integrujących haxe z Drupalem, ale nie są to na razie źródła typu OpenSource. Tym niemniej stworzenie niezależnego projektu rozwijanego przez grupę sprawnych developerów, z którym wiązałyby się zewnętrze fundusze na rozwój, uważam za sprawę jak najbardziej otwartą. Co to jest haxe? haxe jest to interpetowalny, abstrakcyjny język programowania, który pozwala tworzyć kod dający się, teoretycznie, łatwo prze-kompilować do kilku rzeczywistych języków na raz, bez potrzeby wprowadzania większych zmian. Dokładniejszy opis tego języka oraz dokumentacja znajdują się na stronie projektu: Komu potrzebna ta, dodatkowa, technologia? Krótko projektantom i developerom, których główną platformą produkcyjną jest język PHP ( w tym opracowaniu skupię się na Drupalu ), a rozmiary wdrażanych aplikacji i stopień ich skomplikowania wykracza poza zastosowanie kilku standardowych modułów i bibliotek. Do tego wszystkim, którzy, jak ja, mając wcześniejsze, pozytywne doświadczenia w pracy z Javą, ActionScriptem 3.0 i innymi obiektowo zorientowanymi językami, wyposażonymi w kompilatory i /lub środowiska IDE sprawdzające ściśle składnie, pomagające szybko wychwycić błędy i zniwelować wpływ złych technik programowania, odczuwają brak tej cechy dla platformie PHP.

5 Ogólne Korzyści z korzystania z abstrakcyjnego języka obiektowo zorientowanego Programując w języku haxe jesteśmy o stopień abstrakcji ponad dotychczasowymi implementacjami, więc z jednej strony jest to bardziej wymagające zadanie, z drugiej możliwości jakie taki układ nam daje wydają się być w przewadze. Postaram się za chwilę pokrótce omówić zalety takiego podejścia, a w podsumowaniu całości materiału, wytłuszczę również wady. Finalna ocena zależeć będzie oczywiście od konkretnej osoby. Od jej doświadczenia w projektowaniu zorientowanym obiektowo i na stopniu biegłości w posługiwaniu się każdym z języków, do których nasz abstrakcyjny kod może zostać prze-kompilowany. Warto na wstępie zaznaczyć, że brak dobrej znajomości konkretnej platformy docelowej (w tym omówieniu będzie to PHP), w zasadzie uniemożliwia skuteczne korzystanie z haxe. W wielu wypadkach musimy zejść w trakcie implementacji do poziomu konkretnej platformy docelowej, ale przy umiejętnym projektowaniu i wdrażaniu naszych aplikacji, będziemy mogli skutecznie zminimalizować wpływ niskopoziomowego kodu na czytelność, jakość i przenośność. Dodatkowo przewiduje jeszcze szerszy rozwój tej platformy i to, że w niedalekiej przyszłości liczba zewnętrznych bibliotek wzrośnie do tego stopnia, że większość tych niskopoziomowych wstawek zostanie przesunięta na bardzo odległy, nie rzucający się w oczy większości developerów, plan.

6 Analiza wydajności działania aplikacji Różne środowiska docelowe platformy haxe, charakteryzują się czym innym. Prawdę mówiąc są na tyle różne, że po pierwszym zapoznaniu się z tym projektem byłem bardzo sceptycznie nastawiony do tego mechanizmu. Pierwszym projektem, w którym zastosowałem możliwości tego języka była aplikacja do rozpoznawania twarzy na platformę Flash z wykorzystaniem Frameworka FLEX. Nie była to ani aplikacja w całości napisana w haxe, ani stu procentowo autorskie rozwiązanie, a jedynie przepisanie kilku newralgicznych części silnika Kaskady Haar'a do haxe'a i włączeniu tych części do przygotowanego szkieletu aplikacji za pomocą bibliotek *.swc Powody zastosowania (po wcześniejszej analizie) były następujące: 1. Kompilator tego języka daje nam możliwość definiowania funkcji i zmiennych inline (patrz specyfikacja haxe), co przy tym projekcie miało kluczowe znaczenie 2. Możemy tworzyć look-upy zmiennych, dzięki czemu zyskujemy jeszcze większą wydajność 3. Mamy możliwość wykorzystania specjalnych op-kodów Flasha do zarządzania szybką pamięcią, co pozwala nam wielokrotnie przyśpieszyć operację na tablicach danych, w szczególności przy operacjach na obrazie. 4. Szybkość działania, wydajność i stopień optymalizacji kodu przez kompilator haxe->flash jest co najmniej rewelacyjny Efekt był wręcz piorunujący. Po zastosowaniu wszystkich technik opisanych wyżej i po delikatnym re-faktoringu kodu szybkość działania detektora zwiększyła się niemal 5-krotnie. O ile przy wyjściowej aplikacji nie było szans na płynne działanie w czasie rzeczywistym na moim sprzęcie, o tyle po modyfikacjach nie było z tym najmniejszego problemu. Zachęcony tym eksperymentem przepisałem jeszcze kilka swoich (i nie swoich) bibliotek do tego języka i za każdym razem zyskiwałem pozytywne rezultaty. Choćby aplikacja do detekcji ruchu, która jest jedną z szybszych tego typu aplikacji w sieci, z jakimi miałem do czynienia ( dla zainteresowanych opis i sama aplikacja dostępna na blogu firmy Altart: ). Przy targecie PHP niestety nie możemy liczyć na wzrost wydajności przy zastosowaniu ww. technik. Jest to niestety jedna z rzeczy, które w obecnej wersji (haxe 2.05) nie zostały do końca dopracowane. Natomiast, jak napisałem wcześniej, rozwój tej platformy wydaje się być bardzo prawdopodobny, a dopracowanie bardziej wydajnego outputu PHP nie powinno być dla twórcy języka i dla osób ze społeczności bardzo dużym wyzwaniem. Wyeksportowany do PHP kod korzysta w wielu miejscach z funkcji eval(), która niestety nie jest guru szybkości. Stąd moje uwagi co do wydajności.

7 W momencie, gdy do kompilatora haxe dodana zostanie lepsza obsługi targetu PHP'oewgo, jedyne co będziemy musieli zrobić, żeby zaktualizować nasz kod wyjściowy (PHP), to przekompilowanie źródła haxe i wgranie zaktualizowanych plików na serwer. Stu procentowej gwarancji poprawności takiej operacji oczywiście nie ma, więc kopie zapasowe (jak zawsze) będą oczywiście niezbędnym minimum. Target PHP: wbudowany mechanizm automatycznego ładowania klas PHP a języki obiektowo zorientowane Aplikacje webowe napisane w PHP'ie mają specyficzny sposób działania, a sam język PHP nie jest językiem w pełni obiektowym. Zawiera, co prawda, w swojej składni takie twory jak klasy, interfejsy, dziedziczenie i inne, ale sposób tworzenia aplikacji nie przypomina w żadnym stopniu tego do czego przyzwyczajeni są programiści choćby Javy, lub Flexa. Co gorsza, dowolność tworzenia kodu w PHP'ie jest zdecydowanie jego największą wadą, jeśli wykorzystujemy ją w nieprzemyślany sposób. Pozwala skrócić kod o kilka linijek, ale idealnie komplikuje jego zrozumienie i zwiększa prawdopodobieństwo wprowadzenia błędów. Gdy piszemy aplikacje w czystym PHP: tworzenie klas i włączanie ich do kodu, to głównie praca typu: 1. utworzenie odpowiednich klas 2. włączenie klas do wykonywalnego kodu za pomocą dyrektywy include(_once), lub require(_once). Z doświadczenia wynika, że największe prawdopodobieństwo pojawienia się, mają następujące sytuacje: niewłączenie do aplikacji wymaganej klasy niepotrzebne włączenie do aplikacji zbędnej klasy W pierwszym przypadku dostajemy komunikat o nierozpoznaniu klasy, który zazwyczaj możemy łatwo debugować i poprawić ( jeśli tylko nie definiujemy kilku klas o takiej samej nazwie, co nie jest takie do końca trudne w sytuacji programowania bez użycia paczek klas ), a w drugim niepotrzebnie zużywamy zasoby serwera, zmuszając go do parsowania zbędnych linijek kodu. Druga sytuacja już taka łatwa do zlokalizowania nie jest, a chęć jej poprawienia ręcznie prowadzi do pojawiania się w różnych, nieprzewidzianych miejscach kodu, dyrektyw włączających zewnętrzne pliki. W obu przypadkach wymagana jest od programisty zwiększona koncentracja, której i tak nieraz zdecydowanie brakuje. Rozwiązaniem jest tu mechanizm ładowania klas, który język haxe przeźroczyście implementuje automatycznie. Robi to na tyle sprytnie i elegancko, że wiedza odnośnie tego, jak działa, nie jest potrzebna; wystarczy nadmienić że w efekcie haxe wypluwa kod pozbawiony jakichkolwiek dyrektyw include i require, a zamiast tego korzysta z pliku haxe_autoload.php zapamiętującego przypisania

8 między klasami a plikami zawierającymi ich definicje. Zysk jest oczywisty: przy eleganckim projektowaniu aplikacji, w aktualnym przebiegu (wywołaniu danego adresu www mapowanego przez naszą aplikację) kod wykonywalny, składał się będzie z najmniejszego, potrzebnego do poprawnego przebiegu, podzbioru plików klas. haxe a zużycie zasobów Wszystkie mechanizmy języka haxe dodają od siebie za każdym razem, na starcie, kilkanaście/kilkadziesiąt dodatkowych klas umożliwiających poprawne działanie tej platformy. Musimy więc być przygotowani również na pewien wzrost pamięciożerności silnika, niezależnie od rozmiaru wdrażanej aplikacji. Przy dużych aplikacjach ten impakt nie będzie stanowić większego problemu, ale przy małych wdrożeniach będzie to widoczny procent zużycia pamięci serwera. Podsumowanie Samo zastosowanie haxe przy targecie PHP nie spowoduje zwiększenia wydajności aplikacji, a wręcz może doprowadzić do jej większego zamulenia. Do tego wymaganie przetwarzania klas bazowych platformy jest dodatkowym obciążeniem. Jest to sytuacja przeciwstawna do (najbardziej obecnie popularnej) aplikacji haxe dla języka Flash, ale są też pozytywy. Mechanizm automatycznego ładowania uwalnia nas od potrzeby ręcznego śledzenia włączania plików i klas. Przy rozbudowanych i bardzo rozbudowanych aplikacjach jest to istne zbawienie, natomiast wymagane do poprawnego działania, wyjściowe klasy bazowe haxe, są wtedy jedynie nikłym procentem w morzu frameworku tworzonej aplikacji, nie mającym widocznego wpływu na całość

9 Analiza szybkości projektowania, łatwości implementacji i czytelności kodu Postęp w technologiach informacyjnych sprawia, że coraz łatwiej, coraz mniejszym kosztem jesteśmy w stanie oferować coraz bardziej skomplikowane systemy informacyjne, musimy mieć więc jak najlepszą możliwość kontrolowania tego co się w takiej aplikacji dzieje. Drupal CMS jest tego idealnym przykładem Posiadając bardzo rozbudowane zaplecze społecznościowe, które ciągle rozwija, testuje i poprawia kod projektu, umożliwia developerom korzystanie z kodu wysokiej jakości, wspartego nieraz bardzo dobrą dokumentacją. Obecnie Drupal (stan na ) nie wykorzystuje w żadnym ze swoich głównych komponentów źródeł kompilowanych z haxe. Nie spotkałem również ani jednego modułu z repozytorium, opartego na tej technologii. Można optymistycznie założyć, że sytuacja ta ulegnie w końcu zmianie (a osobiście mam głęboką nadzieję, że tak będzie). Jeśli liczba opracowań takich jak to będzie większa, a haxe dysponować będzie jeszcze większym potencjałem wydajnościowym, to prędzej czy później masa krytyczna developerów tworzących aplikacje w ten sposób, zostanie osiągnięta i, w konsekwencji, zmiany nastąpią. Powiedzmy w wersji 9.x Drupala. Ważnym czynnikiem w procesie tworzenia, rozwijania i utrzymania nowoczesnych aplikacji są takie cechy jak: 1. szybkość i łatwość projektowania rozwiązań na platformę działania systemu 2. ujednolicony, standaryzowany sposób implementacji kodu 3. przejrzystość działania, łatwość wprowadzania zmian 4. kontrola błędów na poziomie środowiska programistycznego i/lub kompilatora Programiści PHP są, z natury tego języka narażeni na pojawianie się w trakcie wykonywania (parsowania) kodu aplikacji, błędów składniowych, błędów wynikających z mechanizmu automatycznego rzutowania zmiennych i jeszcze paru innych efektów paskudnej dowolności tego języka. Możliwość pisania kodu w środowisku silnie typowalnym (strong typing), jakim jest haxe rozwiązuje wiele problemów już w trakcie kompilacji i, co za tym idzie, de facto przyśpiesza naszą pracę. Zastosowanie frameworka PureMVC Opis znajduje się na stronie projektu ( Jest to jeden z bardziej uniwersalnych frameworków tworzenia aplikacji opartych o schemat MVC ( Model-View-Controller ), jakiś czas temu doczekał się implementacji również na platformę haxe.

10 Zastosowanie haxe umożliwia nam względnie łatwe wykorzystanie PureMVC (w wersji multicore) jako szkielet budulcowy naszych nowych modułów Drupalowych, co daje nam bardzo duże możliwości i, prędzej czy później, pozytywnie wpłynie na jakość naszego kodu. A dlaczego? Odpowiedź na to pytanie znajduje się w książkach dotyczących szablonów projektowania aplikacji i na forach internetowych. Zachęcam do lektury. A mówiąc krótko: z im bardziej standardowych, sprawdzonych komponentów korzystamy, tym większe prawdopodobieństwo tego że nic nas nie zaskoczy. Praktyka pokazuje, że 95% autorskich rozwiązań można, z powodzeniem, zastąpić ogólnie dostępnymi, opisanymi i sprawdzonymi komponentami. Tak jak było z instrukcją goto ktoś pokombinował i okazało się, że spokojnie wystarczą nam do życia wprowadzone w nowoczesnych językach pętle for i while. Może trochę straciliśmy na możliwości wykorzystania błyskotliwych patentów i ominięcia warunkowego partii kodu, ale zyskaliśmy na czytelności, czyli na parametrze, który w nowoczesnych aplikacjach, w których setki tysięcy linijek są standardem, jest czynnikiem niemal pierwszoplanowym.

11 O czytelności jeszcze słów kilka Jeśli spojrzymy na wygenerowany z haxe kod PHP, to zauważymy jak nieczytelny potrafi on być dla ludzi. Pre-kompilator haxe niezbyt troszczy się o to aby pozostawić kod idealnie czytelnym; dochodzą również do tego dodatkowe warstwy obiektów pośredniczących pomiędzy strukturami haxe a PHP i brak komentarzy. Spójrzmy na przykład haxe ( brak kolorowania składni w haxe wynika z niekompatybilności aplikacji FlashDevelop z OpenOfficem ) /** * Główna komenda inicjalizacyjna modułu Grzegorz Nowak */ package com.altart.drupal.modules.uc_promocje.controller.commands; import com.altart.drupal.modules.uc_promocje.controller.subcommands.checkconfigurationhandler; import com.altart.drupal.modules.uc_promocje.controller.subcommands.registerhookshandler; import com.altart.drupal.modules.uc_promocje.controller.subcommands.registerinitialproxieshandler; import org.puremvc.haxe.multicore.interfaces.inotification; import org.puremvc.haxe.multicore.patterns.command.macrocommand; import org.puremvc.haxe.multicore.patterns.command.simplecommand; class StartupCommand extends MacroCommand { override private function initializemacrocommand():void { super.initializemacrocommand(); /** * Dodajemy pod komendę rejestrującą niezbędne na starcie obiekty Proxy do modeli */ this.addsubcommand(registerinitialproxieshandler); // dodajemy podkomendę inicjalizującą drupalowe hooki this.addsubcommand(registerhookshandler); } // dodajemy podkomendę sprawdzającą poprawność konfiguracji modułu // MICRO RUN-TIME TESTS this.addsubcommand(checkconfigurationhandler); public function new() { super(); } } PHP class com_altart_drupal_modules_uc_promocje_controller_commands_startupcommand extends org_puremvc_haxe_multicore_patterns_command_macrocommand { public function construct() { if(!php_boot::$skip_constructor ) { parent:: construct(); }} public function initializemacrocommand() { parent::initializemacrocommand(); $this->addsubcommand( _hx_qtype("com.altart.drupal.modules.uc_promocje.controller.subcommands.registerinitialproxieshandler") ); $this->addsubcommand( _hx_qtype("com.altart.drupal.modules.uc_promocje.controller.subcommands.registerhookshandler") ); $this->addsubcommand( _hx_qtype("com.altart.drupal.modules.uc_promocje.controller.subcommands.checkconfigurationhandler") ); } function tostring() { return 'com.altart.drupal.modules.uc_promocje.controller.commands.startupcommand'; } }

12 Jeśli wprowadzilibyśmy opcjonalne, dodatkowe mechanizmy pseudo-szyfrujące nasz kod na etapie jego generowania za pomocą rozszerzeń kompilatora haxe, to moglibyśmy uzyskać wyjściowy kod postaci: class 0a2d4a46d515a2f5a75d6dcf80abf4fe extends 4b4775b d8cba6f924e2cd726 { public function construct() { if(!php_boot::$skip_constructor ) { parent:: construct(); }} public function d309154f1411fc00c28c2007c () { parent::d309154f1411fc00c28c2007c (); $this->9310ee909a3fc abbd1521f68( _hx_qtype("com.altart.drupal.modules.uc_promocje.controller.subcommands.registerinitialproxieshandler") ); $this->9310ee909a3fc abbd1521f68( _hx_qtype("com.altart.drupal.modules.uc_promocje.controller.subcommands.registerhookshandler") ); $this->9310ee909a3fc abbd1521f68( _hx_qtype("com.altart.drupal.modules.uc_promocje.controller.subcommands.checkconfigurationhandler") ); } function tostring() { return 'com.altart.drupal.modules.uc_promocje.controller.commands.startupcommand'; } } Uwaga. Ostatni fragment kodu jest wynikiem czysto-ręcznej symulacji po zastosowaniu algorytmu haszującego md5. Obecnie nie ma narzędzi, który umożliwiały by na takie sformatowanie kodu wyjściowego haxe i nie ma też gwarancji, że narzędzia takie w ogóle powstaną. Jedynie wydaje mi się to bardzo prawdopodobne. Rzeczywiste rozwiązania musiałyby zresztą implementować inne funkcje szyfrujące niż banalny md5. Jak widać nie jest rzeczą wyjątkowo prostą zrozumienie mechanizmu działania i kodu wyjściowego na podstawie wygenerowanych źródeł; może to być więc pewnym zabezpieczeniem przed ponownym wykorzystaniem naszej pracy przez osoby trzecie, ale oczywiście nie jest to w żadnej mierze zabezpieczenie stu procentowe. Tak samo jak nie zabezpieczają nas w pełni inne, nawet profesjonalne pseudo-szyfrujące kod PHP narzędzia. Doświadczony programista (zwłaszcza znający haxe) nie będzie miał większych problemów z jego rozpracowaniem, choć nie będzie to już takie oczywiste jak w przypadku podanych na talerzu aplikacji pisanych w czystym PHP zawierających dodatkowo komentarze programisty, a w optymistycznym wariancie, może się to po prostu takiej osobie, czasowo nie opłacać.

13 Przenośność i możliwość ponownego użycia kodu Znana historia Jako sprawni programiści posługujący się więcej niż jednym językiem programowania, mamy zapewne całe biblioteki obsługujące różne sytuacje. Napisaliśmy, powiedzmy, zgrabny framework ułatwiający obliczenia w różnych metrykach w ActionScripcie 3.0, moduł statystyczny w PHP i pokaźną aplikację dla rezerwacji lotniczych w C++. Powiedzmy, że któregoś dnia przychodzi do nas klient i oczekuje że wdrożymy mu system obsługi podobny do wykonanego już wcześniej systemu rezerwacji lotniczych, ale rozbudowany o możliwość kalkulacji tras lotniczych ( wg. specyfikacji klienta najlepiej korzystając z metryki taksówkowej ) i o statystykę rentowności poszczególnych połączeń ( po wstępnej analizie wymagań, okazuje się w dużej mierze zawierającą to, co już wcześniej stworzyliśmy przy okazji innego projektu w PHP). Jest to oczywiście abstrakcyjny, naciągany przykład. Nie wiem czy jakiekolwiek sens ma obliczanie długości tras samolotowych przy użyciu innych metryk niż euklidesowa, a moduły i biblioteki statystyczne powstały już chyba na każdą możliwą platformę. Abstrahując od tego, w takim, idealnym, przykładzie, fakt posiadania podstawy kodu napisanej w przenośnym języku jakim jest haxe, uwolniłby nas od potrzeby przepisywania sporych fragmentów kodu na inne platformy, utrzymywania kodu na tych platformach i wydłużonego procesu testowania kodu. A co z oczywistymi różnicami między technologiami? haxe nie jest magicznym językiem do wszystkiego. To co robi najlepiej, to umożliwienie tworzenia całych połaci kodu, szkieletu aplikacji i modułów w ujednoliconym środowisku, które możemy następnie wyeksportować (pre-kompilować) jako biblioteki/frameworki do innych języków. Części nie dające się ujednolicić musimy, niestety, w ten czy inny sposób obchodzić. Ale z tym problemem poradzimy sobie relatywnie łatwo, jeśli zastosujemy na przykład wspomniany wcześniej framework PureMVC (lub inne podobne, luźne podejście do tworzenia aplikacji). Większość różnic między platformami (Aplikacja internetowa, Flash, Desktop), to sposób generowania warstwy prezentacji oraz sposób przechowywania i pozyskiwania danych z back-endu (mogą to być np.: baza danych, zwykłe pliki aplikacji czy wpisy do rejestru systemowego). Te, zmienne składniki możemy w układzie aplikacji podzielonej na części MVC, łatwo substytuować odpowiednimi komponentami, dla każdej platformy oddzielnie. opis ogólnych, eleganckich sposobów implementacji tego, to temat na osobny, obszerny rozdział na który obecnie czasu brak może uda mi się go zamieścić w kolejnej wersji opracowania, jeśli pojawi się takie zapotrzebowanie. haxe versus Java Java wraz ze swoim hasłem przewodnim napisz raz, uruchom gdziekolwiek zrobiła wielką furorę. Nie za sprawą chwytliwego hasła rzecz jasna, a ze względu na swoją prostotę, elegancję, czytelność i (rzeczywiście) przenośność. Przenośność ta jednak nie jest równoważna temu co, teoretycznie,

14 możemy zyskać pisząc w języku jeszcze bardziej abstrakcyjnym, jakim jest haxe. O ile mi wiadomo to trwają nawet pracę nad opracowaniem pre-kompilatora haxe2java. Mimo iż Java jest niesamowicie popularna w wielu segmentach infrastruktury IT, to nie jest ona dostępna absolutnie wszędzie. Istnieje szereg platform, które Javy nie implementują. Tym obszarem są choćby aplikacje internetowe. Mamy rzecz jasna technologie takie jak JSP, Tomcat, JBoss, ale ze względu na ich spore skomplikowanie i wymagania, nie występują w takiej przewadze jak zwykłe serwery PHP. Dodatkowo skryptowe języki ECMA (JavaScript i ActionScript), to też osobne twory, nie dające się obecnie niczym sensownym zastąpić. W tych właśnie, niedostępnych dla Javy miejscach, haxe spisuje się wyśmienicie, pozwalając programiście skupiać się nad projektowaniem i wdrażaniem solidnej podstawy aplikacji w obiektowo zorientowanym języku i dopiero w ostatecznej fazie integrować ją dla platform docelowych. Można by powiedzieć, że język ten został stworzony właśnie do tego celu. Byłoby to jednak uproszczenie, gdyż wraz z wprowadzeniem możliwości pre-kompilowania kodu haxe do C++ (a w przyszłości nawet do Javy), zyskaliśmy bardzo elastyczne narzędzie po prostu ułatwiające pracę.

15 Integracja haxe'a z Drupalem Do tego momentu starałem się przekonać Cię, do korzystania z języka haxe. Zdaję sobie sprawę, że mój zapał do tego języka w pewnych fragmentach może wydawać się nieco przesadzony, ale pozytywne odczucia w pracy z tą technologią, wiele obiecujących przykładów interplatformowych aplikacji i rosnące portfolio aplikacji opartych na haxe, sprawiają że bardzo ciepło myślę o chwili, kiedy stanie się on standardem. Od tego miejsca postaram się skupić nad głównym założeniem tego opracowania: jak zgrabnie pisać (lub przepisywać) moduły (i podsystemy) Drupala w haxe W związku z tym zakładam, raczej dobrą, znajomość następujących zagadnień: praca z systemem Drupal CMS umiejętność pisania modułów Drupala znajomość podstawowych zagadnień z zakresu obiektowo zorientowanego projektowania i programowania aplikacji i dodatkowo: znajomość haxe (albo przynajmniej przestudiowanie składni tego języka)

16 Platforma developerska Idealny układ do pisania w haxe? Oczywiście idealnego układu nie ma. Wiele zależy od tego na jaką platformę docelową aplikacja powstaje. W następnych ustępach będę zajmował się jedynie pisaniem modułów dla Drupala, więc ze swojej strony mogę zaproponować następujący układ: 1. Jako główny system operacyjny Ubuntu 9.10 (lub ze down-gradeowanym PHP do wersji 5.2 z najnowszą wersją, aktualna, stabilna wersja Drupala 6.x nie współpracuje najlepiej) z postawionym zestawem LAMP, developerską, testową platformą Drupala i wszystkim innym co na co dzień wykorzystujesz w pracy z tym systemem. 2. Jako środowisko do tworzenia kodu haxe musimy niestety skusić się na system operacyjny Windows, gdyż aplikacja FlashDevelop (z której będziemy dalej korzystać) nie posiada swojego odpowiednika Linux'owego, a w wine na chwilę obecną nie specjalnie chce chodzić. Jeśli środowiskiem naturalnym Twojej pracy Drupalowej jest Windows, to rzecz jasna Linux nam do niczego nie będzie potrzebny. Natomiast w układzie prezentowanym przeze mnie, proszę nie myśleć, że korzystać będziemy ze środowiska dual-boot (dwa równoległe systemy operacyjne wybierane przy starcie z GRUB'a). Naniesienie w takim układzie najmniejszych choćby poprawek po stronie haxe, wymagałoby za każdym razem restartowania maszyny. Należy zainstalować ( działanie sprawdzone z VirtualBoxem z doinstalowanym dodatkiem GuestAdditions ) wirtualną maszynę z Windowsem w minimalnej konfiguracji. Wtedy nad wszystkim mamy największą kontrolę i najsprawniejsze działanie.

17 Co jest potrzebne do łatwego tworzenia kodu haxe Będzie nam potrzebne środowisko do pisania PHP najlepiej to które na co dzień wykorzystujesz oraz środowisko do pisania haxe. Jako pierwsze polecam Eclipse jako drugie nie mamy za dużego wyboru - musi to być FlashDevelop (im nowsza wersja tym lepiej. Ja korzystam z 3.x).

18 Konfiguracja Workspace'a Żeby można było rozmawiać mniej więcej o tym samym, proponuje stworzyć następujący, podobny do mojego, układ katalogów i paczek dla tworzonego kodu. Setup dla haxe (program FlashDevelop) 1. Tworzymy nowy pusty projekt haxe'a o dowolnej nazwie i wybranym przez nas położeniu (Project->New Project...) 2. Jeśli nie zostaną stworzone automatycznie, to tworzymy również strukturę katalogów (luźne pliki nas na razie nie interesują) jak na screenie:

19 do katalogu /out będziemy eksportować wygenerowane pliki, a w katalogu /src znajdować się będzie nasz kod źródłowy w haxe 3. dodajemy podkatalog /src/targets. Służył nam on będzie jako zbiorczy pojemnik na główne pliki eksportowe (o tym później) Setup dla Drupala (Eclipse) W zależności jaką metodykę pracy z modułami preferujesz, należy opisaną procedurę dostosować do

20 własnych potrzeb. Ja za najlepszy sposób pracy z podstawą kodu Drupala uważam przechowywanie wszystkich modułów w obrębie jednego projektu PHP. 1. jeśli nie mamy, tworzymy workspace na nasz projekt PHP 2. jeśli nie mamy, tworzymy nowy projekt PHP, będący pojemnikiem na nasz kod i wygenerowane z haxe moduły 3. w ramach utworzonego projektu, budujemy strukturę katalogów na poszczególne części składowe Drupala: pliki z profilami instalacyjnymi, core, patche, themki no i (to co nas, tak naprawdę, jedynie teraz interesuje) moduły. Struktura w moim wydaniu jest rozbudowana ze względu właśnie na pokaźną bibliotekę wtyczek i patchydo Drupala, ale w minimalnej wersji, na potrzeby tego opracowania wystarczy nam jedynie katalog /haxed

21 katalog ten jest de-facto zbiornikiem na 'zwykły' moduł Drupala, dlatego też obecne są w nim pliki *.info, *.install i *.module. Dodatkowo zawiera on jednak następujące specjalne elementy: /cache katalog do obsługi mechanizmu atutoload (opisywanego po krótce wcześniej) oraz miejsce na dodatkowe pliki pomocnicze, wypluwane ze strony haxe. Jest to folder specjalny o specjalnym znaczeniu. Musi on posiadać prawa dostępu przynajmniej 775, żeby serwer i nasz proces PHP mogły zapisywać do niego swoje informacje. Ważna uwaga na boku plik haxe_autoload.php z tego katalogu powinien być kasowany za każdym razem, kiedy wprowadzimy zmianę w wygenerowanym kodzie. Zawiera on przypisania pomiędzy naszymi klasami i ich definicjami, więc jeśli wgramy nowe paczki, albo zmienimy strukturę istniejących, to informacje w tym pliku zostaną zdezaktualizowane, a my prędzej czy później otrzymamy błąd skryptu. /lib folder na pliki-podstawy haxe oraz na nasz wygenerowany kod. Struktura tego katalogu z grubsza odzwierciedla wygląd i układ paczek tworzonych po stronie środowiska haxe. Przeglądając zawartość tego katalogu zobaczymy jak przekompilowane zostały nasze źródła na platformę PHP. Ważna uwaga na boku W katalogu /lib/php znajduje się plik Boot.class.php, obsługujący 'start' haxe dla PHP. Plik ten wymaga minimalnej modyfikacji, aby współpraca z Drupalem przebiegała bezproblemowo. Wersja zmodyfikowana, została dołączona do szkieletu katalogu z modułem haxed, który możesz ściągnąć ze strony projektu haxed-drupal. Warto jednak pamiętać, żeby nie nadpisać przypadkiem tego pliku przez wersję orginalną z haxe podczas eksportowania wygenerowanego kodu. Na szczęście sposoby na łatwe spełnienie tego warunku, bez większego wpływu na użyteczność, istnieją i przedstawiłem je w dalszej części. /modules to tutaj będziemy wrzucali moduły napisane w jakimś stopniu w haxe. Nie jest to prawdę mówiąc koniecznością moglibyśmy spokojnie umieścić je ponad katalogiem /haxed w strukturze modułów Drupala, ale dla porządku, lepiej jest je mieć w jednym miejscu. Wymagany jest również plik haxeindex.php, który jest bezpośrednim łącznikiem, inicjalizatorem zaplecza haxe dla Drupala. Co robimy na końcu z tym wszystkim? Katalog /haxed jest przeznaczony do wgrania na serwer do katalogu/podkatalogu z modułami Drupalowymi (np. /sites/all/modules). Prezentowany jest wtedy na liście z modułami Drupala. Do ściągnięcia Szkielet tego modułu dostępny jest do ściągnięcia ze strony projektu haxed-drupal w archiwum haxed-6.x-1.0.tar.bz2. Udostępnione do ściągnięcia są póki co dwie wersje tego modułu (dla

22 wersji D6.x i D5.x). Przy okazji tego materiału skupię się głównie na wersji 6.x.

23 Przykładowe aplikacje Nie będę opisywać co trzeba robić, aby stworzyć pierwszy działający moduł. Po prostu przedstawię gotowy przykład i wyjaśnię, jakie rzeczy miały miejsce i dlaczego.

24 Przykład modułu Jako przykład modułu, stworzymy haxe'owy odpowiednik udostępnionego jakiś czas temu przeze mnie pluginu (o nazwie first_time_visitor) rozszerzającego możliwości modułu context. W wersji wyjściowej plugin dodawał nam możliwość reagowania na prostą sytuację, w której dana osoba pierwszy raz wchodzi na naszą stronę. Opis i link do źródeł dostępne we wpisie na blogu firmy Altart: Plugin, który będziemy tworzyć, udostępniać będzie dokładnie tą samą funkcjonalność. Różnica natomiast będzie w podejściu do pisania, które z założenia pozwoli nam w przyszłości mocno moduł rozbudować, oraz w tym że będzie można go wyeksportować do kodu działającego zarówno z wersją 2.x modułu Context oraz z wersją 3.x, bez potrzeby powielania kodu w wielu miejscach. Przyjąłem więc następującą nazwę dla nowo tworzonego modułu: context_altart_expander. Osobiście postaram się aktualizować na bieżąco źródła w repozytorium projektu i gotowe pliki wyeksportowane do poszczególnych targetów w miarę rozrostu kodu modułu. Chętnie udostępnię również dostęp do repozytorium SVN wszystkim osobom chcącym dodać coś od siebie. Wszystkie pliki źródłowe są do ściągnięcia ze strony projektu: haxed-drupal Zaczynamy Po stronie PHP (środowisko Eclipse) 1. Tworzymy pojemnik na nasz moduł w podkatalogu /modules modułu haxed:

25 2. Tworzymy pliki modułu: context_altart_expander.info context_altart_expander.module plik *.install nie będzie nam potrzebny 3. Wypełniamy pliki treścią. Plik *.info ma standardową strukturę nie będę nad nim się zatrzymywał. Plik *.module to natomiast nasz jedyny łącznik między PHP a haxe. Na początek wystarczy nam w nim jedna,

26 jedyna linijka: com_altart_drupal_modules_context_altart_expander_initialization:: initialize (); Jej zadaniem jest wywołanie funkcji statycznej obiektu startującego facadę PureMVC po stronie haxe dla tego modułu. Skąd taka dziwna, rozciągła nazwa klasy? Jak zobaczymy później, haxe jest językiem, który posługuje się paczkami klas. PHP nimi, z kolei, się nie posługuję, więc aby zapobiec nachodzeniu na siebie nazw klas po eksporcie z haxe, (mówiąc kolokwialnie) wszystkie 'kropki' z nazwy paczki zamieniane są na 'podkreślenia' i łączone z nazwą klasy. Dopiero taki twór ma prawo zaistnieć po stronie PHP bez ryzyka konfliktów nazw. W tym przykładzie po stronie haxe mamy następującą definicje obiektu startującego ( wyłuskałem jedynie nagłówek klasy ): (plik Initialization.hx) package com.altart.drupal.modules.context_altart_expander; class Initialization { (...) Szczegóły działania nie są na razie specjalnie istotne zajmę się nimi później Powyższe pliki są do ściągnięcia ze strony projektu haxed-drupal w archiwum context_altart_expander-drupal.6.x-1.0.tar.bz2 (lub nowszym) Po stronie haxe (środowisko FlashDevelop) Jeśli chcesz, aby wszystkie czynności opisywane przeze mnie, mogły zostać bezpośrednio zastosowane w Twoim środowisku, sugeruje zachowanie identycznych nazw paczek. Nie jest to oczywiści wymóg i, prawdę mówiąc, przy okazji pisania własnych pluginów w haxe, lepiej żebyś poprzedzał je swoją sygnaturą (np. pl.jackowski.jackek.drupal.modules). Pracę nad modułem po stronie haxe zaczniemy od ściągnięcia frameworka PureMVC i dołączenia go do naszego środowiska haxe. 1. Ściągamy najnowszą wersję PureMVC dla tej platformy: PureMVC w wersji Multi- czy Single- Core? Do pracy w modularnym środowisku Drupala, potrzebować będziemy wersji Multicore tego frameworku.

27 2. rozpakowujemy do katalogu /src w utworzonym wcześniej projekcie haxe w środowisku flashdevelop. W efekcie powinniśmy uzyskać podobną do poniższej strukturę: ( interesują nas jedynie zaznaczone katalogi. Reszta to biblioteki i projekty, które wykorzystuje w swojej bieżącej pracy ) Tworzymy teraz strukturę dla naszego modułu jak na screenie:

28 Tworzymy szkielet modułu, czyli pliki do rozbudowy modułu na bazie szablonu MVC:

29 Mamy już podstawę, którą zaczniemy teraz wypełniać kodem. Gotowe pliki haxe są oczywiście do ściągnięcia ze strony projektu haxed-drupal. Proponuje ściągnąć gotowy moduł, żeby mieć dobry punkt odniesienia do tego co będzie dalej opisywane. Pierwszym najważniejszym elementem jest klasa: com.altart.drupal.modules.context_altart_expander.initialization z pliku Initialization.hx. Jest to ta klasa, której metodę statyczną initialize () wywołujemy z pliku *.module po stronie PHP. Ona (ta metoda), zajmuje się wszystkim co jest potrzebne do utworzenia fasady PureMVC naszego modułu i aktywacji jej silnika. Od tego momentu znajdziemy się już w części czysto obiektowo zorientowanej. Zapraszam do zapoznania się ze źródłem tego pliku jest ono (mam nadzieje) dobrze udokumentowane i nie będzie problemów ze zrozumieniem zaimplementowanych mechanizmów. Nawiązując jeszcze do kodu po stronie PHP: gdyby nazwa naszej klasy była inna, to linijka kodu w pliku *.module musiałaby również ulec zmianie.

30 Jako, że działamy teraz już w środowisku frameworka PureMVC, warto by było, gdybyś znał na tym etapie podstawy pracy na tej platformie. Postaram się, co prawda, opisać mniej więcej newralgiczne miejsca, ale nie gwarantuje, że nie pojawią się niewyjaśnione przeze mnie, specyficzne zwroty charakterystyczne dla modelu MVC w tym konkretnym wydaniu. Layout fasady, komend, modeli i widoków pozwalający na optymalną pracę podczas rozwoju modułu. Mimo oczywistych ram szablonu MVC, sposobów na konkretną implementację danego rozwiązania jest co najmniej setka. Mój pomysł na układ poszczególnych elementów układanki w kontekście tworzenia modułów Drupalowych jest sprawdzony dla małych i średniej wielkości modułów, jest w miarę czytelny i pozwala na elastyczne aktualizację i rozwój. Proponuje ponownie, na tym etapie, ściągnąć kod źródłowy i zagłębić się w implementację. Niektóre katalogi posiadają opisy przeznaczenia, a wszystkie obiekty główny komentarz, pozwalający szybko zorientować się w ich przeznaczeniu. Miejscem w którym zagłębiamy się w fasadę jest publiczna funkcja startup() wchodząca w jej skład. Wysyła ona dalej z kolei informację/komendę (już przy użyciu notyfikacji PureMVC) startującą wszystkie elementy. Pierwszoplanową rolę w tym procesie odgrywa tutaj komenda StartupCommand. W tym, prostym module, jedynym jej zadaniem, póki co, jest uruchomienie pod komendy inicjalizującej wymagane połączenia z Drupalem. W bardziej rozbudowanym module moglibyśmy kazać jej zainicjalizować pewne obiekty Proxy, uruchomić testy konfiguracyjne modułu czy inne potrzebne operacje. Siłą przykładu powinna jego prostota. Wychodząc z tego założenia, zrezygnowałem z rozbudowanego modułu. Jednak, w szczególe, sposób działania i definiowania tych dodatkowych rzeczy wcale taki oczywisty nie jest i wymaga pewnej dodatkowej pracy przy pisaniu odpowiednich bibliotek typu bridge do wielu miejsc Drupala. W planach, z mojej strony, jest jak najbardziej udostępnienie, w ramach projektu haxed-drupal, takiej biblioteki i dołożenie rozdziału opisującego w jaki sposób możemy z niej korzystać, jak ją rozwijać i poprawiać. Ale urlop się kończy, czasu coraz mniej, a jeszcze trochę do napisania. Pozostawię więc tę część do rozważań Tobie, w nadziei, że bez moich wstępnych sugestii wpadniesz na jeszcze lepszy, alternatywny sposób autona zrealizowanie tych elementów. I że się nim ze mną podzielisz. Integracja z Drupalem (hooki, itp.) Integracja modułu z Drupalem odbywa się w pod-komendzie ConnectWithDrupalHandler. Systemami do których się podpinamy jest Context (z pomocą przyjdzie tutaj zdefiiowany niezależnie obiekt ContextPlugin, swoim działaniem nasuwający na myśl szablon Factory) i drupalowy hook_init(). Dzięki umiejętnemu wykorzystaniu opcji warunkowej kompilacji kodu haxe (patrz obiekt ContextPlugin), tworzymy moduł, który, przy niewielkim, dodatkowym nakładzie pracy, może zostać łatwo wyeksportowany do obu wersji (2.x i 3.x) Context'u niezależnie.

31 Dalsze działania obejmują już jedynie nasłuchiwanie na moment wywołania hook_init(), reakcję na ten fakt poprzez odpowiedni handler/komendę i ewentualną reakcję na wystąpienie naszego kontekstu. Eksport kodu Ostatnią rzeczą jaką nam pozostaje zrobić, to kompilacja i eksport kodu haxe do przestrzeni projektu PHP. W tym przykładzie rzeczywiście można pokusić się o napisanie wszystkiego a vista i eksport gotowej całości, ale w rzeczywistych projektach znacznie pewniej będziemy się czuli, jeśli pozwolimy sobie na skontrolowanie naszej pracy pod kątem kompilacji i działania już zaimplementowanych fragmentów. Poniższych elementów nie ma na liście plików do ściągnięcia w ramach projektu haxed-drupal. Kompilacja W katalogu /build/drupal6/modules tworzymy plik buildcontextaltartexpander.hxml,o następującej zawartości: -main targets.drupal.modules.contextaltartexpander -php../../../out/php/drupal6 -cp../../../src --no-inline -D drupal6 jest to plik, który możemy wywołać z poziomu flashdevelop'a. Klikamy na niego PPM i wybieramy opcję Execute. Niestety chwilowo nam to nic nie da, bo potrzebujemy jeszcze dwóch elementów: 1. katalogu na kod wyjściowy 2. punktu wejściowego do kodu ad. 1. tworzymy strukturę podkatalogów w ramach katalogu /out jak na screenie:

32 (interesują nas tylko zaznaczone katalogi) ad 2. haxe w tym aspekcie przypomina sposób kompilacji Javy. Oczekuje klasy startowej, od której mógłby zacząć kompilację, zawierającej funkcję statyczną main(). Musimy mu ją wiec zaproponować. Nie będzie ona miała żadnego wpływu na nasz moduł i jej zawartość nie ma większego znaczenia. Ważne jest tylko to, aby posiadała dyrektywę włączającą inicjalizacyjną klasę naszego modułu. Tworzymy strukturę katalogów jak na screenie (są to podkatalogi katalogu /src):

33 i w ramach ostatniego katalogu plik ContextAltartExpander.hx o następującej zawartości: /** * Punkt wejściowy dla modułu context_altart_expander * Grzegorz Nowak */ package targets.drupal.modules; import com.altart.drupal.modules.context_altart_expander.initialization;

34 class ContextAltartExpander { static function main() { } } Po utworzeniu powyższych plików/katalogów będziemy mogli wykonać, opisany wyżej, plik z dyrektywami kompilującymi moduł: buildcontextaltartexpander.hxml Eksport właściwy Jeśli wszystko przebiegło poprawnie, powinieneś uzyskać podobną do mojej strukturę wyjściową wygenerowanych plików:

35 jedyną różnicą będzie brak w moim kodzie pliku Boot.class.php z podkatalogu /out/php/drupal6/lib/php. Opisywałem wcześniej jaka jest jego rola i dlaczego należy się go pozbyć. Tak uzyskaną strukturę możemy już przegrać do naszego projektu PHP.

36 Ja do tego celu używam stworzonego na boku pliku *.bat, którego dodatkowym zadaniem jest automatyczne usunięcie, przed kopiowaniem, pliku Boot.class.php. Pliki *.bat załączone są do archiwum ze źródłami modułu w haxe: context_altart_axpander.haxe.1.0.tar.bz2, ale zawierają 'wyechowone', dyrektywy kopiujące. Musisz je dostosować do swojego środowiska, żeby miały jakikolwiek sens i uaktywnić. Jeśli korzystasz z VirtualBox'a, to wcześniej należy użyć opcji mapowania dysku sieciowego w Windowsie. Bez tego polecenia w bacie nie mają szans zadziałać. Miejscem wgrania będzie oczywiście (tutaj przenosimy się do perspektywy PHP) katalog /haxed. Kopiujemy tam cały folder /lib z haxe, tak że w efekcie po stronie projektu w Eclipse mamy, podobny do poniższego, widok:

37 Interesują nas jedynie zaznaczone katalogi. Ostatnią rzeczą przed włączeniem modułu po stronie Drupala jest wykasowanie pliku haxe_autoload.php z katalogu /cache.

38 Czy to w ogóle działa? Najlepiej przekonać się o tym, włączając moduł i definiując instancję kontekstu odnoszącą się do sytuacji, w której gościmy na stronie nową osobę. Najlepiej wykorzystać do tego celu drugą przeglądarkę z wyłączoną obsługą ciasteczek, która będzie nam symulowała taką sytuację.

39 Podsumowanie Ostatni dzień urlopu ostatnia strona. Mam nadzieje, że pomysł na wdrażanie modułów w opisany przeze mnie sposób spotka się z pozytywnym odbiorem. Skomplikowanie całości może na pierwszy rzut oka działać odpychająco, ale większość z dodatkowej roboty, wykonujemy jedynie raz, a potem cieszymy się tylko plastycznością naszych rozwiązań i zredukowanym, niemal do zera, ryzykiem popełnienia programistycznego faux pas wykonując dziarskie, acz niezupełnie chciane, konwersje typów co drugą linijkę. Nie muszę chyba wyjaśniać, że przy takim podejściu, z perspektywy wydajności, lepiej sprawdzają się moduły-kobyłki niż moduliki-źrebaczki. Duże moduły niwelują overhead wynikający z zastosowania frameworka PureMVC i silnika haxe, małe nie. Zresztą - już dawno Drupal przestał być lekką platforemką, a stał się moloszkiem. Jeśli dla nas taki, nowy, sposób podejścia do pisania modułów jest stokroć bardziej na rękę, to spadkiem wydajności bym się nie przejmował. Małe aplikacje i tak będą działać, a duże i tak, bez dodatkowych warstw optymalizacji (w szczególności bez statycznie keszującego strony proxy), nie będą. Jaka nowa rzecz nie wydaje na początku skomplikowana i odpychająca? Przecież pierwszy moduł do Drupala też był nie lada wyzwaniem, choć to raptem całe dwa malutkie pliczki -)