ďťż

Budowa CMSa a modułowość Uargumentujcie to bardziej

Podstrony

telcocafe

Myślę nad tym, jak rozwiązać problem z modułowością systemu CMS, ponieważ aktualnie jest to znacznie ograniczone

Rozważam zmianę budowy systemu CMS. Są 2 możliwości.

Rozpoczynanie od bazowego pliku index.php
Podobnie, jak obecnie. Wszystkie podstrony dołączane są z 1 głównego pliku index.php. Tam znajduje się kod główny - m. in. łączenie z bazą, sprawdzenie, ustawienie sesji, dołączanie pliku konfiguracji, początek i koniec kodu HTML, ustawienie skóry i języka, itp.

Plusy:
+ Zapewnienie wykonania podstawowych czynności (wymienionych wyżej) na początku
+ Przejrzystsza budowa (a może odwrotnie)
+ Większa integralność skryptu
+ Prawdopodobnie trochę szybsze działanie

Minusy:
- Ograniczona modułowość
- Pliki główne w katalogach wtyczek muszą być nazwane co.php lub mode.php
- Dłuższe adresy stron
- Brak większej ingerencji w kod HTML (m. in. tytuł strony)

Dołączanie pliku jądra przez niezależne moduły
Są pliki modułów: index.php, news.php, art.php, itp. One dołączają podstawowy plik kernel.php (zawierający większość tego, co w index.php oraz całość inc/func.php). Od nich będzie zależało, czy dołączą później plik odpowiedzialny za wyświetlenie pełnej oprawy graficznej, czy tylko samego środka (bez menu i nagłówka).

Plusy:
+ Niezależne moduły
+ Możliwość większej ingerencji w wygląd i kod HTML
+ moduły nie muszą leżeć tylko i wyłącznie w folderze plugins
+ nie będzie trzeba używać parametrów MODE i CO w pasku adresu ($_GET)
+ możliwość dodania intro lub menu początkowego (coś w stylu pilota na wiadomosc.info)

Minusy:
- Mniejsza integralność
- Kernel.php musi być dołączany do każdego modułu na samym początku.

Które rozwiązanie preferujecie?
Uargumentujcie i uzasadnijcie swoją wypowiedź.
Użytkownik Ferrari edytował ten post 03 grudzień 2006, 11:20

użyj frameworka np. Code Igniter a problemy zostaną rozwiązane. W przypadku CI dodatkowy moduł byłby np. zestawem kontroler + widoki + modele ;) Poza tym użycie frameworka ułatwia i przyśpiesza tworzenie kodu więc zamiast odkrywać koło na nowo warto skorzystać z takiej "pomocy"

Riklaunim: ale gdzie tu satysfakcja?
sam sie zabieram za cmsa - ma to byc cos tworczego, swiezego, nowego,unikatowego - a nie kolejny gotowiec ze zmienionym title

chce miec z tego choc odrobine satysfakcji :>

- Dłuższe adresy stron EE tam mod rewrite i mamy piekne

Ja preferuje index z glownym COntrolerem - oczywiscie MVC - odzielony widok od danych i kontrolera

a pliki dolaczane z katalogow o spojnych nazwach, realizujacych globalnie to samo zadanie.

Riklaunim: ale gdzie tu satysfakcja?
sam sie zabieram za cmsa - ma to byc cos tworczego, swiezego, nowego,unikatowego - a nie kolejny gotowiec ze zmienionym title

chce miec z tego choc odrobine satysfakcji :>

Głupi upór i robienie wszystkiego dwa razy dłużej to też sposób... Swego czasu tworzyłem RkCMF, po tym jak zapoznałem się z frameworkami (Arrow i Code Igniter, Django - python) nie tworzyłbym CMSa od zera lecz skorzystał z frameworka. Tworząc CMS opracowanie kodu np. walidacji formularzy to niezbyt interesujące zajęcie. Framework to nie gotowiec, nie daje "modułów" ani CMSa - ułatwia ich tworzenie ;) CI da ci łatwe tworzenie formularzy wraz ich walidacją, obiektową abstrakcję SQL, wzorzec MVC rozdzielający kod tak jak należy itp. itd.

Głupi upór i robienie wszystkiego dwa razy dłużej to też sposób... Swego czasu tworzyłem RkCMF, po tym jak zapoznałem się z frameworkami (Arrow i Code Igniter, Django - python) nie tworzyłbym CMSa od zera lecz skorzystał z frameworka. Tworząc CMS opracowanie kodu np. walidacji formularzy to niezbyt interesujące zajęcie. Framework to nie gotowiec, nie daje "modułów" ani CMSa - ułatwia ich tworzenie CI da ci łatwe tworzenie formularzy wraz ich walidacją, obiektową abstrakcję SQL, wzorzec MVC rozdzielający kod tak jak należy itp. itd. Ale to tez tak troche glupio ja bym sie czul korzsytajac z frameworka - w koncu to jakby nie moja praca, nie moj skrypt. Wole sam napisac podstawowe klasy, z ktorych korzystam - czyli wlasnego frameworka.

Ja rozwiązałem u siebie to tak:

Mam oddzielne funkcje które tworzą dodają mi html
Oddzielny plik z jądrem (łączenie z bazą itd.)
Każdy plik działu includuje sobie plik ze skórkami i jądrem.
A niektóre pomysły zaciągnąłem z PHP-Fusion.

Jedna rada jeżeli robisz CMS dla siebie to nie warto trzymać wszystkiego w bazie danych jak to przeważnie w CMS-ach jest, tak samo jak prefiksy bazy danych czy inne podobne nie są potrzebne.

Ale to tez tak troche glupio ja bym sie czul korzsytajac z frameworka - w koncu to jakby nie moja praca, nie moj skrypt. Wole sam napisac podstawowe klasy, z ktorych korzystam - czyli wlasnego frameworka.

Jeżeli masz czas i wiedzę to możesz frameworka stworzyć ale to zadanie jest bardziej złożone niż CMS.
Oferta ci: http://www.codeignit...w/features.html
Przykładowy serwis na CI: www.todlaciebie.pl

Sam stworzyłem prosty framework do punBB 1.2 - link, lecz jego funkcjonalność sprowadza się do wzorca MVC oraz kilku pomocników wykorzystujących kod punBB. Nie posiada np. walidacji formularzy, ORMa baz danych itp. itd. samo punBB "ratuje go" bo zapewnia system userów i uprawnień.

Obecnie firmy tworzące na zlecenie dynamiczne serwisy nie tworzą każdego projektu od zera gdyż byłoby to zupełnie nieopłacalne i czasochłonne. Zazwyczaj dana firma ma wybranego jednego frameworka, na którym realizują wszystkie projekty. Sprawdzone narzędzie jest stabilne i można na nim polegać i od razu można rozpocząć prace nad kodowaniem zleconych funkcjonalności a nie klasy formularzy. Oprócz tego inni programiści firmy w późniejszym czasie nie będą mieli problemu ze zrozumieniem i modyfikacją aplikacji. Problemy postnuke czy mambo polegają na tym że nie są zbudowane na bazie frameworka i tworzenie do nich dodatków to koszmar a np. drupal to już "cms z jakimś frameworkiem" i w wielu serwisach funkcjonują mocno zmodyfikowane i rozszerzone instalacje drupala.

Obecnie tworzę nową stronę dla mojego wydziału (ch.pw.edu.pl - stara wersja) i oparta będzie na frameworku django. Obecnie zawiera to moduł stron i wiadomości (+ automatyczny Panel Admina z obsługą użytkowników). Stworzenie tych dwóch modułów ograniczyło się do zdefiniowania dwóch modeli tabel (0% SQL, pełen ORM) oraz wykorzystanie generycznych widoków. Aplikacja została wykonana w 15 minut a nie parę godzin. (kod)

Mam już własny system CMS (nastawiony głównie na szybkość), więc nie będę korzystał z gotowego szkieletu.

Aktualnie bazuje na pierwszym rozwiązaniu. Oprócz wielu zalet są również wady - głównie brak możliwości zmiany tytułu <title> i skomplikowanie budowy modułowej.

Dlaczego rozważam zmiany? W przyszłości zapewne pojawią się bardziej rozbudowane wtyczki, np. forum. Powyższe rozwiązanie komplikuje sprawę. Oprócz tego - przykładowe adresy stron:
- index.php?mode=forum&show=topic&id=10
- index.php?mode=forum&show=admin&a=cats
W folderze plugins musi istnieć folder forum z plikiem mode.php.

Doszedłem do wniosku, że lepsze byłoby rozwiązanie pośrednie. Podobnie jak teraz, plikiem głównym byłby index.php, z którego dołączanych byłoby większość modułów. Co jednak byłoby zmienione? - Część tego pliku zostałaby przeniesiona do pliku funkcji, który wtedy stanowiłby jądro. W ten sposób uniezależnione zostaną niektóre moduły od index.php - np. administracja, zmiana ustawień, pomoc i niektóre podstrony w okienkach.

Plusy:
+ Szybszy start modułów standardowych
+ Częściowa niezależność od pliku index.php
+ Niezależność położenia wtyczek i ich nazw plików

Minusy:
- Wciąż standardowe moduły nie będą mogły zmienić tytułu (ale nie jest to aż tak ważne)

W skrócie:
- index.php służy jako plik podstawowy - odpowiada za wyświetlenie strony ze standardowym modułem
- kernel.php - jądro z funkcjami - dołączany przez index.php i niezależne moduły

Co o tym myślicie? :)
Użytkownik Ferrari edytował ten post 03 grudzień 2006, 12:36
u mnie link do tematu na forum ma postać typu /forum/topic/1/1/ i jakoś straszny nie jest. Nawet bez mod_rewrite możesz mieć lepsze odnośnik - index.php/foo/bar.

Im bardziej kombinujesz tym bardziej trudniejsze rozwiązania wymyślisz. A nastawienie na nanosekundową poprawę szybkości należy do tych podejść bardzie kombinatorskich. Układ plików i kodu ma znikomy, praktycznie niezauważalny wpływa na "wydajność", chyba że kodu jest parę mega i więcej. Jeżeli chcesz optymalizować to najpierw sprawdź kod np. xdebugiem, który profiluje całą ścieżkę wykonywania kodu. "Czas ładowania strony" nie jest w żaden sposób miarodajny.
PHP-Fusion ma oddzielne główne pliki dla każdego modułu co daje trochę powtarzania kodu, postnuke ma pliki modułów wywoływane przez jeden plik wywołujący.

w moim punFrameworku mam proste mapowanie URLi na kontrolery - moduły:
mvc.php?c=NAZWA_KONTROLERA mvc.php?c=NAZWA_KONTROLERA&m=NAZWA_METODY mvc.php?c=NAZWA_KONTROLERA&m=NAZWA_METODY&var1=foo1&va2=foo2
Kod ładujący kontroler:
IF(isset($_GET['c']) and is_file(PUN_ROOT.'punFramework/controllers/'.$_GET['c'].'.php' ) and ctype_alpha($_GET['c'])) { try { include_once PUN_ROOT.'punFramework/controllers/'.$_GET['c'].'.php'; // If method specified try to use it IF(isset($_GET['m']) and ctype_alpha($_GET['m'])) { $action = new $_GET['c']($pun_user, $db, $pun_config, $pun_url, $lang_common); IF(method_exists($action, $_GET['m'])) { echo $action->$_GET['m'](); } else { throw new Exception('Non existing class method: '.$_GET['m'].' for class: '.$_GET['c']); } } else { //no method specified, use default "index" method $action = new $_GET['c']($pun_user, $db, $pun_config, $pun_url, $lang_common); echo $action->index(); } } catch (Exception $er) { $wskaz = @fopen('debug.php', 'a'); @fwrite($wskaz, 'Error Message: '.$er->getMessage()."\n\r File: ".$er->getFile()."\n\r Row: ".$er->getLine()."\n\rIP: ".$_SERVER['REMOTE_ADDR']."\n\r URL".$_SERVER['REQUEST_URI']."\n\rBackTrace: \n\r".$er->getTraceAsString()."\n\r############################################\ n\r"); @fclose($wskaz); message('<b>Script Error! Full error message have been logged.</b>'); } }
Jest jeden kod w jednym miejscu i działa generycznie, nie trzeba robić n-wersji dla n-przypadków.

Co do zmiany tagu title to już twój problem z szablonami. Główny szkieletowy szablon powinien mieć blok w tym tagu a szablony konkretnych modułów nadawałyby określoną wartość temu bloku. podobnie dla meta description.
Użytkownik Riklaunim edytował ten post 03 grudzień 2006, 14:20
Riklaunim chyba dochodza mi do łba Twoje argumenty. Wlasnie przegladam sobie dokumentacje CI, fajnie toto wygląda. Co nie zmienia faktu ze wlasciwy kod jest nie moj :/

Kiedy ten Twój kurs będzie dostępny, kiedyś nie chciało mi sie go czytać, bo oparty był na frameworku, a ja chcialem spokojnie dokonczyc mojego CMS-a, a teraz mi sie zachcialo i caly czas masz DNS-a przekierowywanego :/ Nie mozesz tego na inny serw tymczxasowo rzucic?

problem jest z 2 serwerem DNS - na docelowym serwerze nie działa jeszcze poprawnie i odrzuca przekierowanie, jak się uda to za parę dni powinno być ok.

Co do "mojego" kodu - frameworki tylko umożliwiają tworzenie aplikacji - ty zajmujesz się najfajniejszą częścią czyli tworzeniem funkcjonalności, framework zajmuje się potrzebnymi pierdołami odciągającymi w innych przypadkach od właściwego kodowania.

Musze Ci przyznać racje - fajnie się robi na tym CI :] I zajefajna dokumentacja jest. Następne zleconko zrobie sobie na nim, a w wakacje spróbuje coś własnego stworzyć, parę ważnych klas już mam.

Sitedesign by AltusUmbrae.

Darmowy hosting zapewnia PRV.PL