Idealny CMS
Czytanie może być niebezpieczne. Przekonałem się o tym na własnej skórze po niedawno zakończonej lekturze “Hakerów i malarzy” Paula Grahama. Książka przewróciła mi do góry nogami poglądy na wiele spraw. Graham jest radykałem, ale pisze tak doskonale i przekonujaco, że człowiek co chwila przyłapuje się na myśli: “cholera… ten facet ma rację”.
Szybko i nieuchronnie zbliża się w moim życiu straszliwy dzień. I nie chodzi bynajmniej o przejście Anakina Skywalkera na Ciemną Stronę, ale o obronę pracy magisterskiej. Co prawda jeszcze nie napisałem jednej linijki kodu (o linijce tekstu pracy nie wspominając), ale powoli klaruje mi się wizja Aplikacji.
Temat pracy to “Zastosowanie języka XML do projektowania interfejsów aplikacji internetowych”. Od początku miała to być przykrywka do stworzenia czegoś działającego, na własne potrzeby. Ponieważ jestem szczęśliwcem, któremu udało się wybrać dokładnie taki temat, jaki chciałem pisać (notabene, poza mną na roku w podobnej sytuacji jest może ze 3-4 osoby), więc mogę sobie pozwolić na eksperymenty. Magisterka jest niezłym poligonem doświadczalnym na wypróbowanie pomysłów, które niekoniecznie okażą się trafione. Na pewno lepszym niż komercyjne zlecenie.
Aplikacją będzie następca Fleksa, czyli narzędziem do zarządzania stroną internetową, szumnie zwanym CMS-em. Przyznam, że ciągle nie zdecydowałem, czy i na jakich zasadach będę go upubliczniał po ukończeniu (jeżeli faktycznie do tego ukończenia dojdzie). W grę wchodzi wypuszczenie na licencji MPL silnika oraz podstawowych modułów, np. do prowadzenia bloga, albo utrzymanie status quo, czyli ograniczenie grona użytkowników do mnie i osób, które zdecydują się za to ten ósmy cud świata zapłacić.
Wrócając do teraźniejszości. W ciągu ostatnich trzech lat obejrzałem sporo CMS-ów i spędziłem mnóstwo czasu na pisaniu własnego. W tym czasie Flex był przepisany niemal od nowa pewnie co najmniej pięć razy. Każda kolejna wersja była lepsza, ale gdy w tej chwili patrzę na jego kod, wiem, że dużo rzeczy jest napisane beznadziejnie i na pewno teraz zrobiłbym to lepiej. Wiem też, że za rok nie będę zadowolony i z tego nowego kodu, ale taki już jest urok tego zajęcia.
Jestem właśnie na etapie określania funkcjonalności aplikacji. Poniżej jest lista niektórych pomysłów, które chciałbym zamienić w działający kod. O książce Grahama wspomniałem na początku nieprzypadkowo. To właśnie od niego pochodzi naczelna idea, by stworzyć program, którego sam chciałbym używać. Czy zechce z niego korzystać ktoś jeszcze? Zobaczymy.
Wnętrzności
- Platforma, na jakiej ma działać następca Fleksa to: MySQL 4.x, Apache i PHP 5. Dwa pierwsze składniki raczej nie budzą wątpliwości. A dlaczego PHP 5? Bo inaczej niż czwórka pozwala na pisanie kodu obiektowo, a nie “na klasach”. W tej chwili Flex 0.7 jest pisany z wykorzystaniem klas, ale ograniczenia języka powodują, że nie mogłem w nim wykorzystać pewnych elementów, które powinny poprawić przejrzystość i rozszerzalność kodu, np. interfejsów. Kolejna rzecz to lepsze, natywne wsparcie dla XML-a. Niezależnie od tego, co kto sądzi o XML-u, w końcu jest on w temacie mojej magisterki i muszę coś z tym zrobić :).
- Architektura oparta o MVC. Pewnie niektórzy już mruczą pod nosem, że dzieciak usłyszał o czymś trendy i musi to zaimplementować. Być może. Z drugiej strony to najlepszy sposób na zapewnienie, że zmiany w modelu danych nie będą pociągać za sobą kompletnej przebudowy interfejsu, zatem wybór tego wzorca jest dość naturalny.
- Smarty. Główną słabością obecnej, nieskończonej wersji Fleksa jest brak obsługi szablonów. W nowym wydaniu chciałbym oprzeć na Smarty zarówno samego CMS-a, jak i wykorzystać ten silnik szablonów w stronach zbudowanych z użyciem mojego systemu. Pisanie nowego silnika raczej nie ma sensu, bo Smarty jest dojrzałą aplikacją o dużych możliwościach i szybkości oraz z gotową, dobrą dokumentacją. Odpowiedni moduł w CMS-ie pozwoli na bezpośrednią edycję plików źródłowych serwisu w oknie przeglądarki. Chcę też przygotować gotowe szablony, aby początkujący nie musieli grzebać w ich kodzie.
Funkcjonalność i interfejs
- KISS, czyli Keep it Simple, Stupid! Interfejsy CMS-ów są straszne. Wystarczy wejść na Open Source CMS i obejrzeć je w działaniu. Problem w tym, że deweloper to na ogół ostatnia osobą, która jest w stanie to zauważyć. Dlatego jestem bardzo ciekawy opinii ludzi, które mnie czytają i korzystają z różnych aplikacji tego typu. Co jest w nich złe? Co można poprawić? Co najbardziej Cię denerwuje w aplikacji, której używasz do zarządzania stroną czy aktualizacji bloga? To niepowtarzalna okazja, by ktoś zaimplementował Twoje pomysły, więc czekam na komentarze :).
- WYSIWYG. Ręczna edycja kodu źródłowego to katorga. Dlatego mam zamiar wykorzystać jeden z gotowych edytorów WYSIWYG, ewentualnie przygotować własny. Dodatkowo chciałbym wzbogacić go o import tekstów Worda. Niezależnie od tego, czy lubi się pakiet biurowy Microsoftu, czy nie, możliwość wklejenia tekstu bezpośrednio do przeglądarki i zobaczenia go na stronie jest bardzo wygodna. Jedyny problem to oczyszczenie kodu ze śmieci, jakie ten edytor generuje, ale wbrew pozorom da się to zrobić.
- Wsparcie dla standardów. Chcę, aby tworzenie semantycznego kodu XHTML było jak najprostsze. Mam zamiar zaimplementować bezpośrednią edycję arkuszy CSS w oknie CMS-a (obok wspomnianej wyżej edycji szablonów Smarty, czyli XHTML-a). Sam CMS będzie wymagać przeglądarki z obsługą JS, ale da się go też obsługiwać bez pomocy myszy. Wynika to nie tyle z dbałości o dostępność, ile o wygodę.
- Lista standardowych modułów będzie zawierać nowości, artykuły, sondy, moderowanie komentarzy. Tworzenie nowych modułów powinno być możliwie łatwe.
- Szybkość. Kiedy dwa lata temu zaczynałem pracę nad pierwszą wersją Fleksa, chciałem, aby praca z nim jak najbardziej przypominała pracę z normalnym programem, a nie stroną internetową, która po każdej operacji musi się przeładować. I prawie udało mi się osiągnąć ten cel. W ubiegłym roku, po premierze Gmaila, nagle okazało się, że wszyscy chcą pisać strony wykorzystujące technikę, która ostatnio doczekała się nazwy Ajax. Co konkretnie zamierzam zrobić dla poprawy szybkości?
- Wykorzystać XMLHttpRequest, czyli “latest hype”.
- Zrezygnować ze wsparcia dla Internet Explorera.
Pozwolę sobie zatrzymać się na ostatnim punkcie. Nie ma sensu powtarzać, dlaczego nie lubimy IE. Postanowiłem o nim zapomnieć, aby przyspieszyć proces pisania kodu samego systemu, jak i jego pracę.
CMS będzie wykorzystywać w dużych ilościach JavaScript i CSS. Omijanie błędów przeglądarki Microsoftu zabiera czasem tyle samo czasu, co napisanie poprawnego kodu działającego w normalnych programach. Na dodatek kod JS rozbudowanych skryptów praktycznie zawsze zawiera obszerne bloki w rodzaju:
if (IE) {
// cośtam
}
W wypadku np. edytora WYSIWYG tego nadmiarowego kodu jest już tyle, że znacząco spowalnia on ładowanie strony.
Na pewno nie każdemu się taki pomysł spodoba — raczej nie sprzedam CMS-a żadnej firmie, która ma intranet oparty o IE. Z drugiej strony wiem, że klienta da się przekonać do używania normalnej przeglądarki. No i wspominałem już, że chcę stworzyć program, z którego ja sam chciałbym korzystać, a nie taki, który ma zadowolić 85% rynku.
Kwestią otwartą jest wsparcie dla Opery. Chciałbym, aby mój system w niej działał. Opera w tej chwili nie radzi sobie z edycją tekstu bezpośrednio w przeglądarce. Jeśli nie trafię na jeszcze inne problemy (np. w pracy z XMLHttpRequest), prawdopodobnie przygotuję dla niej uboższą, tekstową wersję edytora WYSIWYG, natomiast pozostałe elementy będą działać jak w Firefoksie. Zobaczymy.
Powyżej napisałem tylko o paru pomysłach, które mam zamiar wykorzystać w swojej pracy. Długość tekstu przekroczyła juz dawno granicę przyzwoitości, więc pozwolę sobie zakończyć.
Liczę na komentarze: można wpisywać nawet najdziwniejsze pomysły na usprawnienie CMS-a. Mile widziani są też kandydaci na betatesterów :).
Łukasz Grabuń
Myślę, że przede wszystkim CMS powinien dbać o wstawianie znaczników ACRONYM i ABBR :-) Obecnie wszystkie XHTML i CMS wstawiane są bez nich.
A na nieco poważniej: rozmawialiśmy o tym, poruszę jednak tę kwestię na forum publicznym: warto, by istniała możliwość statycznego generowania stron. Innymi słowy: dynamicznym generowaniem treści, warto, byś dodał możliwość generowania stron do plików .html, umieszczonych w odpowiednich katalogach.
Szafranek
Będzie. Też denerwuje mnie konieczność ręcznego ich wstawiania . Edytor WYSIWYG chciałbym wzbogacić o przyciski do wygodniejszego wstawiania innych semantycznych znaczników, np.
blockquote,citeczydel.Mam nadzieję, że mi wybaczysz, jeśli wkleję tu fragmenty Twojego maila z argumentami na rzecz statycznych stron.
Tak właśnie jest. Napisanie dobrego systemu obsługi serwisu rozrzuconego po tysiącach plików JEST bardziej kłoptliwe i czasochłonne. Swoje pierwsze skrypty pisałem na plikach, ale od kilku lat korzystam z (My)SQL-a i zapewniam, że z punktu widzenia programisty jest to o niebo wygodniejsze rozwiązanie. Również instalacja systemu pierwszego typu jest trudniejsza — trzeba martwić się o prawa zapisu do plików.
Poza tym mam bardzo przykre doświadczenia z aplikacjami opartymi o pliki. Korzystałem kiedyś z napisanego w Perlu forum YaBB. Miało ono pewien przykry “ficzer”, który ujawniał się przy przekroczeniu quoty. Otóż skrypt otwierał do zapisu pliki, wczytywał ich zawartość do pamięci, a ponieważ nie mógł zapisać ich z powrotem ze względu na brak miejsca, zawartość plików była czyszczona. Gdy trzeci raz z rzędu musiałem ręcznie odtwarzać dziesiątki plików forum, powiedziałem “nie” i przeniosłem się na phpBB. Tam już nigdy nie miałem żadnych problemów tego rodzaju.
Nieprawda. Googlebota nie obchodzi, czy plik jest statyczny, czy generowany dynamicznie, bo nawet nie jest w stanie tego określić. Dla niego liczy się URL, a ten można przygotować w eleganckiej formie nawet na dynamicznej stronie — tak właśnie jest na moim blogu. To, że większość serwisów używa brzydkich URL-i, to całkiem inna sprawa — wynika z tego, że ich autorzy idą po linii najmniejszego oporu.
Ręcznie — być może. Ale od czego są interfejsy do bazy danych? W końcu CMS ma służyć nie tylko do tworzenia nowych wpisów, ale też modyfikowania starych. A jak napisałem wyżej, łatwiej jest napisać interfejs do obsługi bazy danych niż setek plików. Poza tym zawsze można skorzystać np. phpMyAdmina :).
Zdecydowanie nie. Łatwiej jest wyeksportować/zaimportować pojedynczy plik .sql niż setki pliczków tekstowych. Robiłem jedno i drugie — na wolnym łączu backup rozbudowanego serwisu opartego na plikach może trwać godzinami. Gdy do ściągnięcia jest pojedynczy plik z bazą, trwa to najwyżej parę minut.
To słuszna uwaga, ale tylko wówczas, gdy nie korzysta się z cache’owania po stronie serwera. Jeśli strona faktycznie generuje duży ruch, wystarczy włączyć ten mechanizm i w ten sposób wyeliminować konieczność każdorazowego odwoływania się do bazy danych. Podsyłałem Ci wyników swoich testów: włączenie cache’u praktycznie eliminuje możliwość zatkania serwera.
W każdym razie dzięki za uwagi. Czekam na kolejne :).
ultrazbig
Jeśli byś potrzebował betatestera, który korzysta z Opery ;-) …
to byłbym zainteresowany. Nie wiem czy moja znajomość tematu jest wystarczająca ale może przyda ci się “zwykły user”.
Po cichu liczę że Opera dorówna FF w z edycji tekstu bezpośrednio w przeglądarce …
Pozdrawiam
Zbyszek
Łukasz Grabuń
Ech, jestem staroświecki i truskawki cukrem… :-) Na poważnie: tak jestem przyzwyczajony do administrowania moją stroną z poziomu linii poleceń basha, że nie widzę innego lepszego rozwiązania.
Zapewne, po części, kwestia wprawy i przyzwyczajenie. Obecnie nie wyobrażam sobie pracy bez taki narzędzi jak wspomniany bash, czy awk, czy sed, czy nawet perl, którego się uczę. Stworzenie sprawnie działającej bazy danych jest choćby z tego powodu bardziej kłopotliwe, że trzeba zaplanować taki schemat tabel, by po pierwsze, zapewniał on funkcjonalność, której nam w istocie potrzeba, po drugie umożliwiał łatwy rozwój aplikacji, nie wymagający przebudowy 80% systemu.
Ad. backup – znowu kwestia przyzwyczajenia. Mój backup to wget połączone z tarem. :-) Działa równie sprawnie, co tworzenie kopii bazy w repozytorium.
Googlebota przetestuję osobiście.
Szafranek
@Łukasz — oczekiwanie od użytkownika, że będzie potrafił skorzytać z wgeta połączonego z tarem “nieco” kłóci się z założeniami reguły KISS :). Poza tym nie każdy ma dostęp do shella — korzystałem do tej pory z usług trzech providerów i nigdzie nie było go w standardzie.
@ultrazbig — skoro używasz Opery, więc raczej nie posiadasz już dziewiczości “zwykłego usera” (tacy są najcenniejsi jako testerzy), ale będę o Tobie pamiętał :).
bazyli
Widzę, że ambitnie podchodzisz, i fajnie. Książki Grahama jeszcze nie czytałem – z przyjemnością się wezmę. W zamian polecam natomiast “Wariaci rządzą domem wariatów”* Coopera – niemłoda już (7 lat ma chyba), ale bardzo aktualną książkę o projektowaniu pod kątem “zwykłej pani Krysi”.
* – książkę można kupić taniej na stronie wydawnictwa, ale księgarnia wydawnictwa nie ma stałych linków do produktów :/
Łukasz Grabuń
Zasada KISS nie ma nic wspólnego ze znajomością narzędzia wget (zajrzyj na Wikipedię). Zasada ta tyczy się przecież tworzonego oprogramowania (dokładniej: jego funkcjonalności). Moim zdaniem narzędzia UNIX znakomicie oddają ducha tej zasady, wbrew Twemu stwierdzeniu.
Szafranek
Masz rację. Ale to nie zmienia faktu, że wymaganie od użytkownika CMS-a umiejętności korzystania z shella byłoby nadużyciem ze strony projektanta. O pani Krysi ™ już nie wspominam, ale i ja bez skonsultowania się z manem nie poradziłbym sobie z tym zadaniem.
Myślę, że dwa przyciski: import database i export database są prostszym rozwiązaniem.
Łukasz Grabuń
Błędne założenie. To nie użytkownik musi umieć korzystać z shella, a administrator aplikacji. Już samo zarządzanie repozytorium kopii zapasowych wymaga więcej umijętności niż napisanie artykułu i wstawienie go na serwer.
acem
A jak wygląda sprawa przeszukiwania zasobów ?, bazy danych w tym celu są wykorzystywane, a przeszukanie ‘setek pliczków tekstowych’ mija się z celem.
Co do backupu, myślę że każdy sposób ma swoje wady i zalety, jednak w przypadku zastosowania przycisków import export database to rozwiązanie będzie proste i ‘zjadliwe’ dla większości osób, nawet pani Krysi.
Łukasz Grabuń
Przesukiwanie danych jest tak samo skomplikowane, niezależnie od struktury, w której przechowywane są rzeczone dane. Przy niewielkiej liczby plików full-text search jest bardzo efektywne. Osobiście, wolałbym podjąć się napisania prostej wyszukiwarki tego rodzaju dla 100 plików niż iluś-tam wierszy w bazie. To po pierwsze.
Po drugie, dla wielu plików, tak czy siak, trzeba będzie zrobić indeks – a po jego stworzeniu całkowicie abstrahuje się od metody przechowywania danych, czy jest to relacyjna baza danych, czy pliki tekstowe, czy taśmy streamerów. Nie jest to więc argument.
Cleriic
Chciałem tylko zwrócić uwagę na jedną sprawę. Generowanie statycznych stron przez system CMS, nie ma nic wspólnego z tworzeniem serwisu opartego na plikach. Często bardzo obciążone serwisy wykorzystują tę technikę, aby przyspieszyć wysyłanie stron do klienta (przeglądarki). Przykładem CMSa, który posiada taką funkcjonalność to eZ Publish.
Szafranek
Dokładnie. I takie wykorzystanie plików planuję — przy pierwszym odwołaniu będzie generowana statyczna strona o określonym czasie “życia”. Kolejne jej wywołania nie będą wymagać łączenia się z bazą danych.
acem
Na pewno masz rację, ale jaki serwis internetowy korzysta dzisiaj z plików ?. Lepszym i o wiele prostszym rozwiązaniem jest baza danych i najczęściej jest wykorzystywana.
bezspornie się zgadzam :), jednak powyżej rozwinął się inny wątek dotyczący plików kontra bazy danych.
Łukasz Grabuń
Pozwolę sobie umieścić linka do mojej – nieco dłuższej – wypowiedzi na ten temat; ogólnie: każde rozwiązanie ma swoje wady i zalety. Czasami braki stanowią o sile rozwiązania, nie o jego “zacofaniu”.
Oto link do mojego wpisu o blosxom, poruszający temat tego właśnie wpisu Krzysztofa: Moj CMS.
marcin
nie wiem dlaczego ale kiedy lacze sie z swoim kontem ftp/www lub wpisze cos nie tak wyswietla mi sie twoja strona :| , od paru lat samemu programuje w php, tak wiec jesli jeszcze nie masz zamknietej listy betatesterow to prosze o kopie do testow.
Szafranek
Lista betatesterów nie jest zamknięta.
Natomiast jeśli chodzi o zamieszanie z domeną, to nie jesteś pierwszy, który ma ten problem. Ja nie maczałem w tym swoich brudnych palców – spróbuj może napisać do administratora rakieta.pl?
Tomasz Nastulak :: Blog » Blog Archive » Bezpieczna Joomla 1.5.x
[…] Było też wiele wojen (słownych) między miłośnikami Windowsa i Linuxa jeśli chodzi o systemy operacyjne, a na GoldenLine.pl dyskutowano nad wyższości jednych nad innymi systemami cms. Zostańmy przy systemach CMS, by nie zagłębiać się nadto w inne typy/rodzaje/kategorie systemów. […]