Autorski system zarządzania treścią (CMS) dla portali internetowych

Projekt ten rozwija się systematycznie podczas realizacji kolejnych internetowych serwisów bazodanowych (m. in. tego, z którego właśnie korzystasz). Bogatszy o zdobyte doświadczenia, dodaje nowe funkcjonalności i udoskonalam napisane wcześniej mechanizmy, aby strony przeze mnie tworzone były bardziej przejrzyste dla użytkowników, szybsze i bezpieczniejsze. System ten był tematem mojej pracy magisterskiej, którą obroniłem w czerwcu 2010.

    Demonstracja panelu administracyjnego dostępna pod adresem: http://www.ruszczynski.eu/cms/ .

  1. Cel projektu

    2. Celem projektu jest napisanie elastycznego, opartego o wzorzec projektowy MVC, systemu CMS, który można łatwo dostosować do potrzeb aktualnie tworzonego serwisu. Aby to umożliwić, system tworzony jest na bazie niezależnych modułów, które można dołączać do wykonywanych projektów.

  2. Wykorzystywane technologie

    3. System jest napisany w PHP 5, co umożliwia wykorzystanie obiektowości. Najczęściej wykorzystywanym systemem bazodanowym jest MySQL, ale system zaprojektowany jest w taki sposób, aby mógł działać na jak największej liczbie systemów bazodanowych (unikanie tworzenia zapytań specyficznych dla konkretnych baz danych). Aktualna wersja systemu działa w oparciu o XML i transformacje XSLT (po stronie serwera lub klienta). Technologiami wspomagającymi projekt jest javascript, umożliwiająca m. in. wstępną walidację danych po stronie klienta oraz mod_rewrite na serwerze Apache, umożliwiający dla dynamicznie tworzonych stron użycie linków przyjaznych dla wyszukiwarek (SEF).

  3. Korzyści wynikające z zastosowania XML i transformacji XSLT

    4. Fakt korzystania z XML i transformacji XSLT otwiera nowe możliwości przed tym projektem. Obecność XML umożliwia prostą integrację serwisu np. z widgetami lub aplikacjami desktopowymi niezależnie od platformy, na której pracują. Korzyścią z zastosowania XSLT jest to, że możemy łatwo oddzielić warstwę logiki od prezentacji. Co więcej, aby w takim przypadku rozwijać warstwę prezentacji, nie jest wymagana znajomość budowy systemu. W przypadku strony, co do której nie wymaga się interaktywności, możliwe jest wyrenderowanie całej strony i wgranie jej na serwer jako zbiór plików html. Takie działanie znacznie przyśpiesza ładowanie strony przez użytkownika oraz oszczędza zasoby serwera, na którym znajduje się strona. Możliwa jest też sytuacja, że część stron (nie wymagających interaktywności) jest przechowywana jako strony html, natomiast pozostałe są generowane dynamicznie. W przypadku, gdy cała strona jest w postaci statycznych plików html, nie ma potrzeby używania hostingu posiadającego wsparcie dla PHP i systemu bazodanowego (oszczędność kosztów).

  4. Testy wydajnościowe systemu

    5. Testowany system został uruchomiony na serwerze Apache 2.2.9 z PHP 5.2.6 . Całość działała na systemie operacyjnym Ubuntu 8.10 o jądrze 2.6.27-17-generic. Komputer obsługujący linux'a to Pentium 4 2.66 GHz z 1 GB pamięci RAM. Podczas testów było uruchomione środowisko graficzne GNOME. Dla panelu administracyjnego, przy braku jednoczesnych żądań w stosunku do serwera Apache, czas generowania strony praktycznie zawsze był niższy niż 0.3 sekundy, zaś w większości przypadków mieścił się w 0.2 sekundy. Wyjątek w tym wypadku stanowiło wgrywanie/uaktualnianie rekordu z dużą ilością danych np. w formie tekstowej lub plików. Wynikało to z dłuższego wykonywania przez system bazodanowy zapytań SQL lub konieczności wgrania pliku na serwer i opcjonalnie stworzenia miniaturki dla niego. Mając na uwadze fakt, że panel administracyjny raczej nie będzie równocześnie używany więcej niż raz, jest to relatywnie dobry wynik nie powodujący dużego obciążenia serwera. Aby sprawdzić wydajność strony dla zewnętrznych użytkowników, wykorzystano narzędzie ab z pakietu apache-utils, które umożliwia testowania skryptu dla wielu równoczesnych żądań. Do testów użyto głównej strony systemu, zawierającej menu w formie drzewa strony składającego się z 16 pozycji (wartość dla średniej wielkości strony domowej). Pobierany dokument miał objętość 4785 bajtów. Aby zminimalizować opóźnienia związane z transferem danych, testy przeprowadzono na tej samej maszynie na której uruchomiono serwer Apache z aplikacją. Pierwszy test składał się ze 100 nierównoczesnych żądań (polecenie: ab -n 100 http://127.0.0.1/system/pl/home/ ). Testy zostały wykonane w 3.854 sekundy, co daje średnio 38.543 milisekundy na jedno żądanie. Oznacza to, że w ciągu sekundy serwer jest w stanie obsłużyć 25.95 tego typu żądań. Kolejny test składał się z 500 żądań o identyczną jak w poprzednim akapicie stronę, lecz w tym momencie cały czas było 10 równoczesnych prób pobrania tego samego dokumentu (polecenie: ab -n 500 -c 10 http://127.0.0.1/system/pl/home/ ). Test trwał 19.686 sekundy (5.1 razy dłużej niż poprzedni test co świadczy o tym, że podczas równoczesnych żądań do serwera jego wydajność jest minimalnie mniejsza). Pojedynczy użytkownik musiał średnio czekać 393.715 milisekund. W ciągu jednej sekundy serwer działający pod takim obciążeniem był w stanie obsłużyć 25.4 tego typu żądań.
    Opisywane tutaj testy dotyczyły systemu nie korzystającego z żadnych form cache'owania (przechowywania w pamięci podręcznej często używanych informacji w celu przyśpieszenia działania serwisu) co sprawia, że istnieje duży potencjał do zwiększenia wydajności prezentowanego systemu.

  5. Praktyczne przykłady wykorzystania systemu

    • Strona domowa ruszczynski.eu

      • Celem strony jest zaprezentowanie treści w języku polskim i angielskim. Do treści przyporządkowywane są zdjęcia i ich opisy w obydwu językach. Ze względu na brak częstych aktualizacji strony, w tym przypadku wgrano na serwer statyczne pliki HTML reprezentujące wszystkie możliwe odwołania do systemu.

    • Panel administracyjny Grunwaldzkiej Gry Internetowej (ggi.waw.pl)

      • Projekt ten to gra internetowa czasu rzeczywistego napisana dla Wspólnoty Drużyn Grunwaldzkich. Opis gry znajduje się w moim portfolio. Do zarządzania w sumie ponad 50 tabelami związanymi z grą użyto panelu administracyjnego będącego częścią opisanego tutaj systemu. Była to jedna z pierwszych wersji CMS'a, nie posiadająca m. in. walidacji po stronie klienta za pomocą javascript.

    • Panel administracyjny do importu i zarządzania danymi makroekonomicznymi dla portalu forsal.pl

      • W projekcie tym zastosowano praktycznie najnowszą wersję panelu administracyjnego. Posiada on obsługę importu w formacie CSV przystosowaną do specyficznej struktury danych (źródłem w tym przypadku jest konsola Bloomberg). Ponadto możliwe jest przeglądanie i edycja danych w tabelach, do których istnieje możliwość importu.

  6. Perspektywy rozwoju

    7. Niewątpliwą zaletą systemu jest fakt, że można go przystosować do praktycznie dowolnej struktury bazy danych. Możliwe jest np. zrobienie panelu administracyjnego do zarządzania danymi innej aplikacji webowej. Fakt ten znacznie rozszerza liczbę osób zainteresowanych tego typu rozwiązaniem. Obiecującym polem do rozwoju aplikacji jest przystosowanie jej do kolejnych systemów bazodanowych (obecnie obsługiwany jest MySQL i Postgres). Priorytetem w tym wypadku jest integracja z SQLite a w dalszej kolejności z komercyjnymi bazami takimi jak MSSQL czy Oracle.

    Podsumowując, przedstawiony tutaj system posiada wiele różnych zastosowań oraz możliwości rozwoju.

  7. Ekrany z systemu


Ekran wyboru możliwości panelu administracyjnego Ekran dodawania rekordu Ekran edycji rekordu Ekran wyświetlający dane dla wybranej tabeli




Projekt i wykonanie: Krzysztof Ruszczyński (w oparciu o własny system CMS)
Grafika dostarczona przez jcd.pl