Tworzenie sieci miedzy komuterami wim 98 SE a win XP
Tanie tworzenie stron www
tworzenie skrótów w ubuntu 7.10
Program do tworzenia przewodników wideo
Frei Program do tworzenia muzy
Szukam prostego, ładnego i fajnego CMS'a...
[PHP][CMS] "Przyjazne linki" - implementacja
[CMS] Newsy i grupowanie - tagi?
[PHP] CMS i szablony - jak połączyć?
silnik 2.0 brak napiÄcia na wtryskiwaczach ....
chomiki
Skryptowi F3Site przyjrzał się programista z certyfikatem Zend. Postawił kilka zarzutów:1. Dlaczego strukturalnie?
2. Brak mechanizmów cache
3. Brak mod_rewrite
4. Użycie global, za co powinienem wychłostać się (to nie ta epoka)
1. Dlaczego strukturalnie?
Skrypt nie jest napisany w pełni obiektowo - podobnie jak PhpBB 3, PunBB, phpMyAdmin i cała rzesza CMS-ów. Dla każdego żądania tworzy obiekty do obsługi bazy danych (PDO) i szablonów (własna klasa Content). Napisałem też klasy do zapisu konfiguracji, wysyłania e-mail i PW, nadzoru nad zapisem pozycji, budowania RSS, kompilowania szablonów i instalacji systemu dla każdego języka. Mimo to architektura jest strukturalna.
Pozostaje pytanie: czy wszystko trzeba pisać obiektowo?
Pisząc obiektowo, można ułatwić tworzenie i modyfikowanie aplikacji lub całkowicie poplątać kod. To zależy od podejścia i dobrze zaplanowanej architektury.
Płatne skrypty forum vBulletin i IPB są napisane obiektowo.
1.1. Wydajność
Twórcy kodu strukturalnego twierdzą, że stawiają na wydajność. Tak samo twórcy kodu obiektowego. Dobrze napisany kod strukturalny lub strukturalno-obiektowy musi być szybszy od w pełni obiektowego. Ładowanie X klas, tworzenie obiektów, wywoływanie metod - to wszystko wpływa na czas i użycie pamięci. Styl programowania może nie ma największego wpływu na wydajność, więc przejdźmy dalej.
Do przeglądarki i tak serwer wysyła tylko kod HTML. Strony są składane w locie - to nie jest tak, jak w aplikacjach okienkowych lub skryptach JS. Tam jest pełna obiektówka nawet wskazana. JavaScript jest w całości obiektowy.
2. Brak mechanizmów cache
Aktualnie stosuję cache dla najważniejszych komponentów, np. menu, lista najnowszych pozycji, hierarchia kategorii, menu w panelu admina... Ogólnie czasochłonne operacje są wykonywane tylko raz. Przykład: liczba pozycji w kategoriach jest zapisywana w bazie danych.
To za mało. Zarzucił, że skrypt za każdym razem wykonuje zapytania do bazy danych - bez żadnego cache. Weźmy przykład: wyświetl listę prywatnych wiadomości albo listę artykułów na stronie 2.
Bazy danych mają własny mechanizm cache. Czy to prawda, że wystarczy zmiana jednego warunku i wszystko leci od nowa? Czyt. gdy zmieni się fragment po komendzie WHERE - szczególnie w połączeniu z poleceniem JOIN.
Gdyby tak tworzyć cache wszystkich zapytań? Wtedy można ominąć w ogóle połączenie z bazą danych. Ogromny wzrost wydajności. Tylko to raczej nie zawsze jest możliwe, szczególnie gdy włączymy panel "osoby online" (przy dużym ruchu).
2.1. Przeznaczenie
Nikt nie będzie na takim skrypcie budował Naszej-Klasy albo Dziennika Internautów, który po padzie GG też miał problemy z wydajnością. Google na pierwszym miejscu wyświetlał news z tego serwisu. Później udostępnili lekką wersję.
CMS, który osiągnąłby najlepszą wydajność, generowałby po prostu strony .html. To jednak jest niemożliwe. Logowanie, dynamiczna zawartość, która zależy od preferencji.
Czy dodatkowe mechanizmy cache są więc potrzebne? Czy raczej powinno stosować się specjalne rozszerzenia do pamięci podręcznej?
3. Brak mod_rewrite
Na początku zamierzałem wprowadzić obsługę mod_rewrite. Zrezygnowałem z 1 powodu. Zbyt dużo kombinowania. Musiałbym zmienić sposób tworzenia linków, a wtedy straciłbym kompatybilność z wersją 2.1.
Obecnie: ?co=art&id=5&page=2
Krótki link: /art/5/2 albo /art/5/tytul-artykulu/2
Kilka reguł w .htaccess i można z powodzeniem wprowadzić krótkie URL-e, ale to dość toporny sposób. Dlaczego? Otóż skrypt musi obsługiwać także zwyczajne URL-e. Nie ma też uniwersalnych reguł dla wszystkich modułów. Nie - przy obecnej architekturze nie da się w pełni wprowadzić krótkich URL.
Tutaj znów wracam do przeznaczenia. Na większości darmowych hostingów krótkie URL-e są wyłączone. Sytuacja zmienia się na lepsze, ale np. na DHost wciąż nie ma obsługi mod_rewrite. Podobnie z subdomenami.
4. Słowo global
Bardzo krytykowane w środowisku OOP. Zazwyczaj zastępowane singletonem, choć nie widzę wielkiej różnicy (jedynie obiekty nie są dostępne w globalnym zasięgu, a tam żadna klasa nie ma nic do szukania). Singleton na pewno można zastąpić lepszym wzorcem.
Przy obecnej architekturze nie da się ominąć global. Podobnie w PhpBB 3 - ten deklaruje jeszcze więcej zmiennych globalnych w funkcjach.
To nie tyczy się tylko Twojego CMS'a. A moje forum?
Zapewne od razu zostałby zjedzony przez ekspertów za pseudoklasy, "global" pseudocache ostatego postu i inne tego typu rzeczy. Nie przejmuj się i wyznawaj zasadę - skoro NIKT nie pomagał Ci pisać skryptu, tak naprawdę - pisz go swoim stylem. Ale nie masz nic do stracenia - F3Site jest szybki. Nie piszesz tych aplikacji dla firm (chodzi mi głównie, w sensie komercyjna), dlatego krytykę zawsze możesz posłuchać, niekoniecznie się stosować się do jej zaleceń
Pozdrawiam
Ok, czyli najlepiej olać krytykę i robić po swojemu? Czyli będę robił strony na tabelach i miał w dupie to, że nikt poważny już tak nie robi? Bo robię za darmo i to usprawiedliwia odwalanie kichy, tak?
Świetna filozofia.
pim, nie chodzi o kichę - jeżeli chodzi o powagę - chodzi o styl pisania. WebCM jest ograniczony, gdyż dostosowuje się pod gorsze serwery.
Nie ignoruję krytyki - dlatego powstał ten temat. Nie można też bezkrytycznie stosować się do wszystkich rad i postulatów. Pierwsza wersja F3Site 1.0 powstała 4 lata temu, kiedy jeszcze królował PHP 4 i włączony register_globals. Nieczytelny kod, złe podejście i błędy. Wtedy ignorowałem błędy E_NOTICE. Większość minusów przetrwała do 2.1.
Podczas tworzenia F3Site 3.0 miałem wiele koncepcji rozwiązania różnych problemów. Na początku całkowite oddzielenie warstwy prezentacji (HTML, CSS, JS) uważałem za zbędne - nawet w PA. Teraz wiem, że na forach mieli rację. Podobnie z bazą danych, gdzie obiektowe podejście jest lepsze wraz z mechanizmem podpinania (prepared statements).
OOP vs procedural, mod_rewrite, cache każdego zapytania - to tematy do dyskusji
Duże firmy i serwisy zamawiają CMS u specjalistów dostosowany do ich potrzeb albo kupują komercyjny. Ewentualnie tworzą samemu. Tutaj w grę wchodzą obiektowe frameworki typu: Zend Framework, Kohana, Symfony. Raczej nikt nie korzysta z darmowych CMS-ów. Wyjątkiem są fora, systemy obsługi błędów, wiki...
Rozszerzę jeszcze niektóre kwestie:
Krótkie URL
1) domena.com/article/50 - wymaga mod_rewrite
2) domena.com/index.php/article/50 - wymaga PATH_INFO
3) domena.com/index.php?page=article/50 - zadziała wszędzie
4) domena.com/index.php?co=article&id=50 - tradycyjne URL-e
1) to najlepsze wyjście. Część darmowych hostingów obsługuje mod_rewrite.
2) zadziała na większości darmowych hostingów, choć nie na każdym
3) nie sprawi kłopotu na żadnym serwerze
1) jest najbardziej pożądany i ma większy sens
2) lepsze to niż nic
3) raczej nie ma sensu, ale przy implementacji krótkich URL może być alternatywą
Co o tym sądzicie?
nie można jakoś dynamicznie generować linków jakąś funkcją, dzięki czemu byłaby opcja do włączania mod_rewrite ?
Można stworzyć funkcję lub dodawać prefiks, ale z tym wiąże się szereg innych zmian. Trzeba podawać wszędzie bezwzględną ścieżkę do plików, skryptów, arkuszy CSS...
1) Część szablonów zawiera ścieżki do podstron lub innych plików. Być może da się automatycznie wstawić odpowiedni prefiks regexpem.
2) Dotyczy to też adresów obrazów, miniatur, plików do pobrania... nad tym należałoby zapanować. Raczej nie można wymagać od adminów lub redaktorów, aby podawali ścieżkę bezwzględną - mogą w ogóle nie wiedzieć, o co chodzi mimo podpowiedzi. Z tym chyba nie będzie kłopotu po zastosowaniu odpowiednich funkcji.
Po prostu HTTP jest niedopracowany. Gdy tworzono ten protokół, nikt nie wiedział, że powstaną technologie typu PHP i dynamiczne serwisy.
Jak wprowadzić krótkie URL w istniejącym projekcie?
1) Przebudować strukturę URL na hierarchiczną - chyba najlepszy sposób - niestety stracę kompatybilność z poprzednimi adresami, chyba że skrypt będzie zamieniał stare na nowe. Wystarczy 1 reguła w .htaccess, która przekieruje do index.php?url=...
2) Wprowadzić wiele reguł w .htaccess - skrypt obsługiwałby 2 rodzaje adresów:
$url = (NICE_URL) ? '/pms/view/50' : '?co=pms&act=view&id=50'; Zacząłem wprowadzać to rozwiązanie, ale wstrzymałem się właśnie z powyższych powodów.
Zastanowię się, co zrobić. Na pewno nie w F3Site 3.0. Raczej w wersji 3.1 lub 4.0.
Zostają jeszcze zaawansowane mechanizmy cache. Przy obecnych zastosowaniach raczej nie ma sensu zapamiętywać wyników każdego zapytania. Większe zagrożenie powodują dodatkowe żądania, aby pobrać obrazki - szczególnie w edytorze. Coś z tym muszę zrobić.
Czyli jednym słowem w tej wersji wprowadzenie mod_rewrite było by zbyt skomplikowane.
A cache? Cache powinien być, jeśli mówimy o słabych serwerach. Jednak nie dla każdego zapytania. Strona główna i inne podstrony powinny być w cache'u, a po logowaniu - cache się wyłącza i strona jest bezpośrednio wczytywana. Jaki to ma sens? Ano taki, że jak Google wyświetli news na samej górze listy wyszukiwania, to raczej osoby wchodzące na niego nie będą się logować.
dla mnie cache nie ma większego znaczenia. Dlaczego?
Weźmy aspekt 1000 użytkowników. Cache'ujemy całą stronę. Ktoś dopisuje komentarz/posta czy coś tam. 1000 stron do edycji. Jaki ma to sens. Albo inny. Właśnie przy zapisywaniu cache'u masz bardzo duży zapis na dysku - bardziej męczy to serwer, że zamiast tylko zczytać, powiedzmy z MySQL'a to na dodatek zapisuje. Owszem, można zapisywać, ale tylko takie poszczególne rzeczy, typu konfiguracja strony, ew na forum ostatni post / kategorie i działy, nic więcej
Dlatego cache ma sens tylko w dużych serwisach.
Napisałem już wyżej coś na temat 1000 użytkowników i dopisywaniu jednego posta.
Trochę zboczę z tematu - poruszę użyteczność systemów CMS.
Kilka lat temu serwisy społecznościowe nie były tak popularne. Na Forum Eksperta nie brakowało ludzi mimo cenzury. Biliśmy rekordy popularności. Ostatnio więcej ruchu, ale to nie ta sama atmosfera. Ambitni użytkownicy zakładali amatorskie serwisy i strony o komputerach. Zazwyczaj na własnym skrypcie, choć często sięgali po CMS-y. Po rewolucji społecznościowej większość upadła, a pozostałe przeszły metamorfozę i zajmują się teraz tylko konkretną dziedziną informatyki. Wyjątkiem są serwisy, którym udało się zatrzymać czytelników lub trzymają się mocno barierki pomimo niskiej popularności.
Historia wortalu COMPMaster i skryptu F3Site
W tym okresie (2004) powstał COMPMaster. Początkowo miał być rozbudowanym wortalem z osobnym menu dla każdego działu, ale nie udało mi się zebrać wielu osób do współpracy. Pozostałem przy 1 menu. Powstało tylko kilka kategorii. Artykuły napływały - serwis powoli rozwijał się.
Oparłem go o własny skrypt bez PA. Informacje o artykułach i plikach znajdowały się w plikach w postaci tablic PHP. Wystarczyło użyć pętli FOR, aby je wyświetlić. Stworzyłem okienko z opcje użytkownika opartymi o cookies, np. skórka, układ nawigacji, opisy plików pod nazwą lub w dymku, wyświetlanie porady dnia...
Kiedyś w KŚE był test CMS-ów. Wybór padł na szybki PHP-Fusion. Brakowało w nim funkcji, które istniały w autorskim skrypcie dla COMPMaster, np. tekst powitalny dla kategorii, grup plików / artów na 1 stronie (tego i tak nie ma), większej przejrzystości, bloków menu z linkami... Całkowita zmiana wyglądu utrudniona. Tak narodził się skrypt F3site.
Rozwój F3Site
W 2005 opublikowałem F3Site 1.0. Ciężko z popularnością, brak skórek, choć zdobyłem zwolenników. Teraz mogę stwierdzić, że nawet mocno ulepszona wersja 2.1 nie spełniała podstawowych założeń.
Premiera 3.0 dopiero po 3 latach od wydania 2.0 / 2.1. Przez ten czas spacerowałem po stronach o PHP, blogach programistów, uczyłem się pisać lepszy kod. Dużo wolnych chwil zmarnowałem, zastanawiając się nad implementacją różnych funkcji lub siedząc na różnych stronach / grach / forach. Błąd kardynalny nr 1.
Patrząc na efekt pracy - stwierdzam, że CMS jest wciąż niedopracowany mimo ciekawych rozwiązań. Sytuacja jest gorsza. Brak aktualnych wtyczek (aktualnie 1), skórek, współczesnej szaty graficznej w wortalu COMPMaster, który ten skrypt rozpowszechnia. Aktualnej skórki chyba nikt nie potrafi przerobić, bo jest oparta o warstwy <div> i CSS. Licznik pobrań skoczył w górę, więc może w przyszłości będzie więcej zadowolonych userów. Na OpenSourceCMS skrypt otrzymał od internautów niską notę: 2.8/5 (6 głosów). W statystykach widzę, że ktoś w Holandii zainstalował CMS, ale nie potrafi go w ogóle skonfigurować. F3Site jest jeszcze w kilku dużych katalogach. Jeśli wykorzystam potencjał, mogę odnieść sukces. W przeciwnym wypadku natychmiastowa porażka. Na razie popularność zdobył tylko skrypt F3Sonda, mimo że nierozwijany od kilku lat
Wróćmy do tematu - czy teraz warto tworzyć własny CMS w pojedynkę?
Po rewolucji w Internecie spora część uczestników for przeniosła się do serwisów społecznościowych.
Można zadać pytanie, czy warto kontynuować skrypt, który w obecnym formacie NIE jest przyszłościowy. Zawsze znajdzie się ktoś, kto sięgnie po CMS, aby stworzyć stronę domową z własnymi programami, portfolio, witrynę klubu piłkarskiego, ale mimo to przegram z porządnymi skryptami, zazwyczaj tworzonymi przez firmę z wykwalifikowaną kadrą.
Aby skrypt liczył się na rynku CMS-ów, musiałbym podjąć próby ratowania:
* stworzyć nowe skórki albo zaadoptować jakieś darmowe [open source]
* jak najszybciej wydać 3.1 z Nice URL, lepszym interfejsem, tagami, wyszukiwarką...
* stworzyć ciekawe rozszerzenia
* uprościć zarządzanie treścią, modyfikację kategorii...
* przebudować główną witrynę COMPMaster
Teraz pozostaje pytanie, czy jeszcze istnieje popyt na lekkie CMS-y nastawione na treść, a nie na społeczność. Może warto przerzucić się na inne projekty zamiast tworzyć CMS?
[ Dodano: 2010-01-28, 22:41 - czytać ODTĄD ]
