Gra jako podstrona serwisu

A dlaczego nie?! Co się będziemy ograniczać! Tak więc jedną z podstron mojego najnowszego CMS-a jest gra zręcznościowa "Snake". Wystarczy wejść i można od razu grać. Grę można obsługiwać zarówno myszką (dotykowo na tabletach), jak i klawiaturą (na stacjonarnych kompach).

Pomysł był taki, aby przepisać grę, którą kiedyś napisałem w wersji desktopowej (na Windows), na wersję webową, tak aby nie trzeba jej było do uruchomienia ściągać. Ale w praktyce napisałem ją od nowa - tak było łatwiej. I przyjemniej!

Gra jest dostępna pod adresem: http://angular-cms.pl/page/13

Projekt Angular

Przyszedł czas na zaprzyjaźnienie się z front-endem. Dotychczas cały wysiłek wkładałem w backend, bo tam leżała cała logika aplikacji. Niezależnie, w jakim języku apka została napisana - czy to PHP, czy Python, czy Java. To serwer obsługiwał żądania użytkownika i generował widok. Tworzenie przyjemnych dla oka efektów wizualnych na stronie nie było możliwe za pomocą backendu. Mając na uwadze to ograniczenie, postanowiłem przyjrzeć się bliżej "drugiej stronie medalu", czyli front-endowi. Zacząłem bawić się Javascriptem, potem wziąłem na warsztat jQuery, który w połączeniu z AJAX-em i JSON-em bardzo mnie zachwycił swoją prostotą, a jednocześnie potęgą działania. Zrobiłem mały projekt, który wykorzystuje wspomniane technologie. Wyszło całkiem zgrabnie.

Ale wciąż nie dawał mi spokoju pewien zamysł, który chodził za mną od kilku lat. Chciałem zrobić apkę webową, która by działała podobnie jak apka desktopowa. To znaczy taką apkę, która miałaby jeden niezmienny szablon, a w nim pojawiałyby się dynamicznie różne, zależne od kontekstu, dane. W praktyce oznacza to brak przeładowywania całej strony przy zmianie kontekstu. Na przykład, gdy chcemy wyświetlić inną podstronę, nie odbywa się wczytywanie jej od nowa, a jedynie następuje podmiana danych w stale wyświetlanym szablonie. Takie zachowanie jest cechą tzw. Single Page Applications, czyli aplikacji jednostronnych.

Aby taką aplikację napisać, wystarczy HTML, Javascript i źródło danych (baza danych na serwerze, plik na dysku itp.). Można to zrobić ręcznie, ale wymaga to mnóstwa wysiłku. I tu z pomocą przychodzą przeznaczone do tego frontendowe frameworki. Ja wybrałem AngularJS, bo mi najbardziej odpowiada. Dzięki niemu można szybko i sprawnie napisać aplikację webową tego typu. Chcąc więc poznać Angulara, poczytałem trochę teorii, liznąłem trochę dokumentacji i zacząłem pisać swoją apkę.

Ponieważ chciałem w niej mieć system zarządzania oparty na autoryzacji, czy jak kto woli autentykacji, musiałem rozwiązać problem przydzielania dostępu - i to zarówno w części frontendowej, jak i backendowej. Autoryzacja po stronie serwera jest konieczna, ponieważ logikę autoryzacji po stronie klienta można podejrzeć i złamać (po stronie serwera nie jest już tak łatwo). Tak więc, mając zrobioną podwójną autoryzację, mogłem wykonać system zarządzania stroną. W efekcie powstał projekt Angular CMS, prosty CMS, którego teraz będę wypełniał treścią.

ORM na Javie

Skoro aplikacja pracuje na bazie danych, logiczne wydawało się zaimplementowanie w niej ORM-a (mapowania obiektowo-relacyjnego). A cóż to za diabeł?! Jest to po prostu zbiór klas zawierających pola, które są ściśle odwzorowane na kolumny odpowiednich tabel w bazie. Czyli każda tabela w bazie posiada swój odpowiednik w postaci klasy. Jak to wygląda, opisałem w artykule ORM - mapowanie obiektowo-relacyjne.

Apka na Javie ruszyła

Postanowiłem nauczyć się Javy. Ponieważ najbardziej leży mi Web, wziąłem na warsztat Java EE. Poszukałem sobie darmowej platformy hostingowej dla aplikacji javowych. Znalazłem taką - OpenShift. Założyłem konto, zacząłem instalować proste, szkoleniowe apki, aby potestować różne zagadnienia. A więc: jak działają serwlety, jak wygląda obsługa formularzy, jak łączyć się z bazą. Jak już podstawy miałem opanowane, rozpocząłem projekt CMS-a w Javie. I po dwóch miesiącach intensywnej pracy powstała niezła apka, którą można obejrzeć na żywo: http://cms-jfrmwrk.rhcloud.com. Zapraszam do obejrzenia!

FineCMS - dodać edytor czy nie?

W trakcie pisania frameworka miałem poważne wątpliwości, czy powinien on umożliwiać edycję szablonów i arkuszy stylów strony wprost z panelu admina. Są to przecież kluczowe, a nawet krytyczne elementy strony, które w razie błędnej edycji mogą popsuć cały jej układ. Jednak z drugiej strony bezpośrednia edycja szablonu oraz arkusza stylu staje się tak potężnym narzędziem w rękach administratora, że aż żal byłoby z czegoś takiego rezygnować. Po dłuższym wahaniu zdecydowałem, że edytor szablonu i stylu musi się pojawić. W końcu dostęp do niego ma jedynie administrator, a jest on (przynajmniej powinien być) osobą świadomą tego, co robi. W efekcie w panelu admina widzimy dwie nowe ikonki: "Szablon" oraz "Styl".

Już po pierwszych testach dołączonego edytora stwierdzam, że dzięki nowym funkcjom elastyczność systemu ogromnie wzrosła. Dosłownie można się bawić w przebudowywanie układu i wyglądu. Tak więc była to doskonała decyzja, "jedyna słuszna koncepcja". :)

Strona projektu: FineCMS

Nowy projekt - FineCMS

Tym razem napisałem od nowa frameworka MVC. Zupełnie inna architektura, całkowicie odmienione i poprawione front controller, dispatcher, router. Kod jest bardziej spójny, elegancki, łatwiejszy w zarządzaniu. Na tym frameworku postawiłem nowego CMS-a. Użyłem tu Twitter Bootstrapa do widoku oraz PDO do modelu. Poprawiłem też paginację list. Dzięki nowej architekturze udało się uprościć instalator aplikacji.

Początek był trudny. Zanim ukształtowała się obecna postać frameworka, wiele razy podchodziłem do stworzenia właściwej architektury. Gdy zaprojektowana struktura nie była do końca spójna, odbiegała choć w jednym miejscu od ustalonego standardu, albo było w niej coś, co mi się nie podobało, wtedy usuwałem dane rozwiązanie i wracałem do punktu wyjścia, próbując stworzyć rozwiązanie w inny sposób, dopóki nie powstało coś, do czego nie miałem zastrzeżeń, co było zgrabne i eleganckie. Takie podejście stosowałem wielokrotnie w trakcie całego projektu. Jednak najwięcej takich nieudanych prób było na początku, zanim nie wyłonił się ogólny schemat, którego trzeba było się potem trzymać. Wówczas kolejne rozwiązania przychodziły same, bo wynikały z istniejącej już architektury. Gdy framework stał się kompletny, można było osadzić na nim CMS-a. Tak też zrobiłem i w obecnej postaci CMS ma wszystkie podstawowe funkcjonalności. Jego rozbudowa o kolejne jest ułatwiona dzięki ustalonemu standardowi, którego wystarczy się trzymać - prowadzi on za rękę podczas tworzenia nowych funkcji.

Strona projektu: FineCMS. Zapraszam do obejrzenia.

CMS - mechanizm kontroli dostepu Access Control List (ACL)