Podstrony
- telcocafe
- [PHP+MySQL] Problem z połączeniem mysqli('localhost', 'xxx', 'xxx', 'xxx'
- [PHP] Wyrażenia regularne. Zamienić name="info_imie" na name="{info_imie}"
- [php] Dodanie textu do pliku. Problem... :) POMOCY!!!!!!!!!!!!!
- Dobre programy do edycji php Dobre programy do edycji php
- [PHP] podział na strony php: podział na strony
- [PHP i MySQL] jak pobrac liczbe rezultatow Jak pobrac liczbe rezultatow???
- jak zrobic aktualizacje php? pomocy!!!!!
- Błąd w PHP-Fusion pomocy !!!!!
- Daczego nie dziala?? skrypt php nie chce działać!!!
- [PHP] - Sonda. Pomocy!!!
- zanotowane.pl
- doc.pisz.pl
- pdf.pisz.pl
- gawitanowice.opx.pl
telcocafe
Jak powinien wyglądać idealny CMS? Po 5 latach doświadczenia w tworzeniu skryptu zarządzania treścią, a może bardziej systemu portalowego, mogę podzielić się wnioskami.Jesteśmy świadkami dynamicznego rozwoju Internetu. Zmienia się rynek oprogramowania. Na co należy postawić w 2010 roku? Do pożądanych cech na pewno zaliczymy:
Od strony praktycznej
1. Integracja z serwisami społecznościowymi
2. Łatwe zarządzanie treścią - dla każdego
3. Przyzwoity domyślny wygląd i działający serwis po instalacji
4. Duży wybór skór, dodatków i innych fajerwerków
5. Interfejs, który skraca i ułatwia pracę, bez zbędnego klikania
Od strony teoretycznej
1. Uniwersalny API
2. Możliwość rozszerzania funkcjonalności w dowolnym miejscu
3. Czytelny kod - komentarze, podział warstw
4. Szybkość - wydajne algorytmy, cache, optymalizacja żądań
5. Podział ról w całym skrypcie - najlepiej zacząć od projektowania
Wątek dotyczy rynku low-end i middle-end, czyli rozwiązań przystosowanych do wielu potrzeb, często tworzone dla mas. Odbiorcy nie są wymagający - mniej interesuje ich strona teoretyczna. Ciekawy interfejs ma większą siłę niż funkcjonalność pod warunkiem, że nie brakuje najbardziej pożądanych funkcji, które agresywnie reklamuje konkurencja. Podstawowym wymogiem jest niewątpliwie wygoda nawet w klasie hi-end.
Wracając do teorii, na pewno część funkcji (np. rejestrację, logowanie) wsadzę do API. Tutaj pojawia się problem. Załóżmy, że integrujemy CMS z forum. CMS korzysta z PDO, a forum z MySQLi. Forum dołącza jeden z plików API i wywołuje funkcję lub metodę, która dodaje nowego użytkownika do bazy. Zaraz... Przecież potrzebujemy obiektu PDO, ustawień, plików językowych... Dołączanie tych plików nie należy do kompetencji kawałka kodu rejestruj().
Kolejna rzecz - rozszerzanie dotychczasowej funkcjonalności. Bez tego można zapomnieć o integracji z serwisami społecznościowymi, dodatkowymi polami w profilach... Są 2 koncepcje:
1. Wbudować wsparcie dla API serwisów społecznościowych, wydzielić obszary do rozszerzenia
2. Stworzyć CMS, który można dowolnie rozszerzać - łatwiej w pełni obiektowym skrypcie
PunBB robi to tak:
1. Wczytaj uchwyty (hooks) z pliku cache
2. W wybranych miejscach: dla każdego pożądanego uchwytu wykonaj eval(kod)
Bardzo prosta metoda, ale niezbyt bezpieczna. Poza tym traci się kontrolę nad obszarami.
Na co należy postawić, projektując współczesny CMS?
Na razie tyle. Można dyskutować pozostałe punkty. Zachęcam wszystkich do dyskusji.
Jak powinien wyglądać idealny CMS? Po 5 latach doświadczenia w tworzeniu skryptu zarządzania treścią, a może bardziej systemu portalowego, mogę podzielić się wnioskami.
5 lat może i tworzysz, ale coś co nie istnie na rynku i trudno wnioskować coś o rynkowych CMSach na takiej podstawie. Nie odpowiadasz za rozwój Wordpressa czy Drupala.
Od strony praktycznej
1. Integracja z serwisami społecznościowymi
2. Łatwe zarządzanie treścią - dla każdego
3. Przyzwoity domyślny wygląd i działający serwis po instalacji
4. Duży wybór skór, dodatków i innych fajerwerków
5. Interfejs, który skraca i ułatwia pracę, bez zbędnego klikania
Wordpress i zrobione
Od strony teoretycznej
1. Uniwersalny API
2. Możliwość rozszerzania funkcjonalności w dowolnym miejscu
Skórki i gotowe moduły starczą. Co bardziej ambitni popełnią własny moduł
3. Czytelny kod - komentarze, podział warstw
4. Szybkość - wydajne algorytmy, cache, optymalizacja żądań
5. Podział ról w całym skrypcie - najlepiej zacząć od projektowania
Na 3 nie licz, poza tym 3,4,5 - mało kogo to obchodzi. Dla klienta ma działać, a że w kodzie pełno tricków i hacków to go nie obchodzi/nie wie. CMS nigdy nie będzie czytelny ani z ambitnym kodem.
Wątek dotyczy rynku low-end i middle-end, czyli rozwiązań przystosowanych do wielu potrzeb, często tworzone dla mas.
Wordpress i podobne na proste stronki i Extreme/PHP-Fusion na różne zazwyczaj beznadziejne stronki ;)
Odbiorcy nie są wymagający - mniej interesuje ich strona teoretyczna. Ciekawy interfejs ma większą siłę niż funkcjonalność pod warunkiem, że nie brakuje najbardziej pożądanych funkcji, które agresywnie reklamuje konkurencja. Podstawowym wymogiem jest niewątpliwie wygoda nawet w klasie hi-end.
Ma wyglądać i ma się klikać jak klient chce. Tyle go obchodzi.
Wracając do teorii, na pewno część funkcji (np. rejestrację, logowanie) wsadzę do API. Tutaj pojawia się problem. Załóżmy, że integrujemy CMS z forum. CMS korzysta z PDO, a forum z MySQLi. Forum dołącza jeden z plików API i wywołuje funkcję lub metodę, która dodaje nowego użytkownika do bazy. Zaraz... Przecież potrzebujemy obiektu PDO, ustawień, plików językowych... Dołączanie tych plików nie należy do kompetencji kawałka kodu rejestruj().
Jak jest rozbudowany projekt to zazwyczaj nie używa się juz ogólnego CMSa i nie zlepia się serwisu z takich "ogólnych" skryptów. Także potencjalnemu klientowi nie zaimponujesz jeżeli na jego potrzebę dedykowanego skryptu odpowiesz lepieniem jednego z drugim. Powyższe dla CMSa to przekombinowanie. Obecnie masowy CMS jest na proste i/lub głupie stronki nie wymagające niczego więcej poza podstawowymi opcjami.
Kolejna rzecz - rozszerzanie dotychczasowej funkcjonalności. Bez tego można zapomnieć o integracji z serwisami społecznościowymi, dodatkowymi polami w profilach... Są 2 koncepcje:
1. Wbudować wsparcie dla API serwisów społecznościowych, wydzielić obszary do rozszerzenia
2. Stworzyć CMS, który można dowolnie rozszerzać - łatwiej w pełni obiektowym skrypcie
2. nigdy nie stworzysz. Od tego są frameworki i dedykowane aplikacje. Plus masa roboczogodzin.
1. zaorasz się na śmierć a i tak mało kogo to zainteresuje, czy i tak dla danej osoby okaże się bezużyteczne.
Bardzo prosta metoda, ale niezbyt bezpieczna. Poza tym traci się kontrolę nad obszarami.
A kogo to obchodzi? Działa? działa.
Na co należy postawić, projektując współczesny CMS?
Olać to i zająć się opanowywaniem najlepszych technologii i języków na rynku. Jak chcesz dobrą pracę to nie CMSiki tylko frameworki, czy też np. Ruby, Python, Groovy. Za "zainstaluj mi Pan wordpressa" dostaniesz niewiele, nauczysz się zero i tyle samo dodasz do portfolio - chyba że jesteś frontendowcem i robisz wypas skórkę do niego jeżeli o dziwo ma uczciwą kasę na to co chce dostać. Natomiast za projektowanie i rozwój dedykowanych aplikacji zarobić można znacznie więcej, praca jest bardziej pewna a i doświadczenie z takiego projektu spore.
Nie ma sensu tworzyć kolejnego wiekopomnego CMSa w pojedynkę bo to strata czasu. Nikt na tego CMSa nie czeka bo ma miliard innych, w tym kilka liderujące i najbardziej sprawdzone. Nowi gracze jeżeli gdzieś się pojawiają to mają za sobą odpowiednią dużą firmę, fundusze i sporo roboczogodzin wielu programistów.