StatiCMS

[lame]

Witam

Od jakiegoś czasu po głowie chodzi mi koncepcja tzw "statycznego cms'a".
Rozważam rozmaite koncepcje, przeyszedł czas na próbe uporzadkowania myśli
i rozwiazania dostrzeżonych problemów.

Moze na poczatek sam koncept:
static cms z zalozenia nie powinien roznic sie niczym do zwyklego cms'a
poza tym, ze jak najwiezej podstron ma byc przechowywanych i wywolywanych podczas odwiedzania ze statycznych plikow .html
profitow z odpalania statycznych plikow chyba nie musze tlumaczyc, strony odwieraja sie niezwlocznie, obciazenie serwera jest bardzo niskie, niestety pojawia sie szereg problemow, ktore przy dynamicznym generowaniu nie wystepuja:

- ilosc plikow, kazda podstrona to plik .html, przy ograniczeniach na ilosc plikow na hostingach moze pojawic sie problem, potrzeny jest jakis system zarzadzanai iloscia przechowywanych plikow statycznych i usuwania w razie potrzeby tych najmniej waznych (najzadziej odwiedzanych lub/i najktocej generowanych) tutaj pojawia sie problem z przechwytywaniem informacji o tym jak czesto odwiedzana jest konkretna podstrona, jedyna opcja to dealing z logami serwera www, a to chyba zbyt duza komplikacja..

- sesja/zalogowanie, static cms ma realizowac opcje podobne do bloga/forum/serwisu spolecznosciowego, wszystko to potrzebuje funkcji logowania, jesli gdzies na stronie ma widniec informacja "zalogowany/a", to nie moze byc ona na stale wlepiona w HTML'a, musi byc generowane przez JS z danych przechowyanych cookie, prawidlowa walidacja tych danych bez przeliczenia przez skrypty po stronie serwera jest niemozliwa, zatem w cookie bedzie musialo byc przechowywane cos na ksztalt; "logged_as=username", sesja zostanie porzadnie przewalidowana dopiero kiedy user bedzie chcial sie dobrac do wrazliwych podstron typu "edycja profilu", ta podstrona i inne calkowicie indywidualne w zalenosci od usera beda musiala byc wygenerowana dynamicznie.

- jezeli user bedzie chcial odpalic podstone dla ktorej nie istnieje plik statyczny, htaccess przekieruje do skryptu generujacego widoki, ktory na poczekaniu taki plik utworzy, mam nadzieje ze ta kwestia byla dla kazdego jasna od poczatku wykladu

- przykladowy event, dodanie komentarza: Zalozmy ze jest sobie podstrona z jakims artykulem, możliwe ma być dodawnie komentarzy, user chcac dodac komentaraz wypelnia formularz, potem klika submit, ktory kieruje do dynamicznej czesci CMS'a, tworzony jest nowy widok z komentarzem, a stary statyczny plik widku (jescze bez tego komentarza) nadpisywany... trzyma sie kupy co nie?

mam nadzieje, ze zalozenia projektu sa jasne, 99% odwiedzin ma sie odwolywac do statycznych plikow .html, cachowanie i uruchamianie nawet najprostrzego skryptu przy kazdym wywolaniu strony stoi w sprzecznosci z celem calego przedsiewziecia.

No, troche to sobie uporzadkowalem, zwykle pisze takie pierdoly sam do siebie a potem kasuje, tym razem przyspamie na forum.

Czekam na Wasze uwagi.

Pozdrowienia

[TQM]

Swietny post i dobry kierunek myslenia!

Wiec do rzeczy:
1. takie CMSy juz istnieja od dawna i to nie jeden a zdecydowanie wiecej - np moj blog jest zrobiony takim wlasnie CMSem, wiec ja pisze content a system generuje statyczne pliki. Content moge generowac prosto na serwerku albo na swoim kompie w domu i statyczne HTMLe wraz z obrazkami itd wrzucac na serwer via FTP/scp/rsync nawet za pomoca skryptu odpalanego z Cron'a. Wydajnosciowo czas ladowania takiej strony bije na leb na szyje kazdego wordpressa czy inna dynamiczna platforme.

2. nie spotkalem hostingu co ograniczalby ilosc plikow... ograniczane jest miejsce na dysku, pojemnosc bazy MySQL czy czego tam uzywasz, pojemnosc skrzynek itd wiec ograniczanie sie co do ilosci plikow nie ma wielkiego sensu imho

3. czesci dynamiczne strony stanowia pewien problem, bo musisz na serwer wrzucic czesc aplikacji ktora odpowiada za modyfikacje zawartosci i tu pojawia sie dylemat - jesli modyfikacja odbywa sie raz na iles to nie ma sensu trzymac tego jako proces w pamieci tylko odpalac na zawolanie choc to kosztuje wiecej czasu... i tutaj np masz komentowanie postow - nie wiem czy spotkales sie z takim czyms jak spam w kontekscie blogow... masz robota ktory przez cale dni probuje wyslac reklame jakiegos gowna aby pojawila sie pod twoim postem... jedn, dwa boty - nie problem... znajdz 10-20 i mozesz miec sliczny DoS bo takie cos wyczerpie nie tylko polaczenia (te trwaja baaaardzo dlugo w porownaniu do pobierania HTMLi) a do tego zjadaja ogromne ilosci pamieci... i tu dochodzimy do kolejnego elementu

4. Jelsi na poczekaniu re-generujesz strone i wyswietlasz nowy content to majac pare osob komentujacych post mozesz miec problem, ze 2 wpisy beda chcialy dodac sie w tym samym czasie i nasapi race-condition. W zaleznosci od tego jak to jest techniczne rozwiazane i jakie mozliwosci ma serwer, bardzo latwo zniszczyc caly wpis - nadpisujac albo robiac smietnik z wpisu (czlowiek uczy sie tego w bardzo bolesny sposob).

5. Obsluga sesji - nie ma to wielkiego sensu imho jesli robisz to po stronie klienta. Podstawowe zalozenie, klient jest 'be' i chce zrobic cos zlego. Jesli nie dzialasz wg tej zasady to dobrze ci zycze ale kiepsko wroze


Pierwsze co mi przychodzi do glowy aby te problemy rozwiazac...
1. Content trzymasz w plikach/bazie i generujesz na polecenie admina uzywajac przygotowanych szablonow, dostajesz statyczny html i wysylasz na serwer aby bylo dostepne dla ludzi...
2. Komentowanie postow - nie dzieje sie natychmiast czy tez automatycznie ale wpisy sa wrzucane do plikow ktore ida do moderacji przez wlasciciela strony. Autor wpisu podaje swoj mail i haslo zabezpieczajace jego wpis - przyda sie pozniej aby dodac jakis mechanizm szybszej niz reczna autoryzacji wpisow - wracajacy user ktoremu raz zatwierdzono post moze postowac dalej.

Zbudowanie takiego CMSa nie jest jakos specjalnie trudne - jeden taki zbudowalem juz w firmie, drugi wlasnie buduje (potrzebne jest wiecej funkcji niz ten stary oferuje). Kombinuj kombinuj - kierunek ktory sam podales jest moim zdaniem bardzo dobry ale poszukaj slabych punktow jak czas wykonania, co sie stanie jesli ilosc ruchu wzrosnie (zapomnij o dostepie do logow, nie wchodzi w gre), co zrobic z aktualizacja postow?

[lame]

ad 4:

O zniszczenie całego posta bym się nie przejmował, informacje potrzebne go jego wygenerowania przechowywane są w bazie danych, która sama w sobie ma na to zabezpieczenia.
Mam też na to inną koncepcję, nazywam to roboczo "CronCMD",
chodzi o to, że kazda akcja, typu dodanie komentarza/posta, nie jest wykonywana kompleksowo na poczekaniu, jedyne co się dzieje, to dodanie do specjalnej tabeli w bazie danych, informacji potrzebnych do wykonania zadanej akcji przez cykliczny proces uruchamiany przez CRON'a (powiedzmy raz na 5 min)

Przykład: dodanie komentarza:

Zapytanie POST powoduje dodanie w bazie danych zserializowanej tablicy typu:

action => 'comment',
'post_id' => '123',
'content' => 'to jest komentarz'
'title' => to jest tytul,
'timestamp' => time(),
itp...

cyklicznie uruchamiany proces przetwarza te dane i wykonuje pelna operacje (w tym rzecz jasna wygenerowanie nowego widoku)

plusy:
+ male obciazenie serwera, poniewaz zapytania wykonywane są szybko, wszak to tylko jedno zapytanie do bazy (insert)
+ cykliczny cron bedzie potrafil rozpoznac, ze np. zakolejkowano kilka komentarzy do jednego postu, wiec zamiast generowac kilka razy widok, zrobi to tylko raz.

minusy:
- user bedzie musial poczekac ~5 minut na prezentacje efektow jego akcji, (w dużych portalach jest to standard)


- - - - - - -

ad 1:

Tak, tylko że generowanie contentu poza serwerem uniemożliwia wszelkie operacje właściwe dla współczesnych platform CMS, nie ma możliwości dodania komentarza, posta, zakladnia kont, logowania, ogolem wszystkiego co aktywne. Moje potrzeby są inne.

- - - - - - -

ad 2:

Jest ich dosyc sporo szczególnie w Polsce, gdzie nadal panuje mania przycinania czego się tylko da (w sumie nie ma co się dziwić, taki mamy profil użytkownika), np. nazwa.pl, o darmowych hostingach nie wspomne.
Cóż, chyba pozostaje to olać i mieć nadzieje, że CMS nigdy nie osiągnie takiej ilości podstron aby ten problem się pojawił, jednocześnie CMS będzie w stanie zwrócić podstrone nawet jeśli nie powiedzie się utworzenia statycznego widku, po prostu zrobi to dynamicznie.

- - - - - - -

ad 5:

odnośnie sesji to tak jak wcześniej napisałem, potrzebna jest takowa do obsługi akcji indywidulnych, jak np. edycja profilu czy edycja postu, takie funkcje musza być realizowane przez "StatiCMS", to jedno z podstawowych założeń.
Jedyne niedociągnięcie, to to, że user będzie mógł przez modyfikacje cookie spowodować napisanie na strone "zalogowany jako Admin", poza chorą satysfakcja z takiego stanu rzeczy nic innego mu nie przyjdzie, poniewaz odwarcie chronionych podstron będzie wymagało dynamicznego przewaklidowania sesji, zazwyczaj też ponownego zalogowania..

[TQM]

Cron to bardzo fajne podejscie... i ten rsync tez da sie zrobic z con'em wiec nie problem... mozesz miec maly skrypt ktory zapisuje gdzie dane na serwerku itd i lekko modyfikujesz proces publikacji aby te zmiany uwzglednic zanim powstanie nowa wersja strony.

Oczywiscie nie zalatwia to mozliwosci modyfikacji wlasnego profilu (jako usera) czy edycji posta...

Zanim zaczniesz pisac, zobacz jakie sa juz teraz CMSy dostepne do tego - jest ich co najmniej kilka, takich co generuja statyczny content oraz takich co nawet bazy dancyh nie uzywaja (bo nie potrzebuja). Jedna sprawa to miec CMS a druga miec cos co pozwala czytelnikowi dodawac content - te systemy trzeba nieco rozdzielic moim zdaniem.

[lame]

Zapodasz linki do takich CMSow?

Hm edycji postów tym nie załatiwe, prawda, do tego potrzebne są w każdej chwili najnowsze wyniki... i tak chyba będzie z realizacją każdego aspektu, póki się da to statycznie, potem jak najwydajniej, a na końcu biała flaga i klasycznie (dynamicznie)

To czy publikować zmiany natychmiast, czy cronem, czy po akceptacji przez admina musi być zależne od ustawień, przy tym chce uratować troche wydajności i opcje konfiguracji zapisywać w plikach, szybciej wychodzi includnąć niż querować baze.

Mam jeszcze jeden pomysł na edycje postów, tylko że do tego potrzebny jest JavaScript.

Mianowicie:
User wrzuca post, post czeka na cykl cona aby zostać opublikowanym, ale user dosteje sztuczną (widoczną tylko dla niego) prezentacje posta przechowywaną w JS, w przypadku otwarcia strony w nowym oknie przeglądarki, te zmiany będą jeszcze niewidoczne (czekają na crona).
User będzie mógł edytować post pracując na kopii przechowywanej w JavaScripcie, dla niego wynik będzie zawsze aktualny, inni na ostateczną wersję będą musieli poczekać te kilka minut.

Najsłabszy pukt, to to, że taka strona musiała by być odpalona w ramce, w przeciwnym razie nie ma możliwości przechowywania danych w JavaScripcie (cookie jest za małe).

Sam nie wiem, to mocno naciągane, ale wykonalne..

[TQM]

do tego dojdzie problem z refreshem... ja bym sie nie bawil w takie cos...
ciezko mi cos doradzic, kombinuj, testuj...


Movable Type - potezna maszyna majaca od cholery opcji... Perl/CGI plus pare modulow - swietnie chodzi (MovableType.org - Home of the MT Community)
Webby - ciekawy projekt zrobiony w Ruby, do tego potrafi serwowac na zywo strony uzywajac wbudowanego serwera i automatycznie re-generowac HTML jesli strona sie zmienia (Webby :: Webby)