CMS - założenia wstępne, Co o tym myślicie? Opcje

[elnino.pl]

W ciągu kilku najbliższych dni rozpocznę prace nad nowym projektem - CMS. Ogólne założenia są następujące:

• Otwartość kodu (licencja GNU/GPL lub podobna własna)
• Obiektowość (> php 5)
• Integracja z bazą danych dzięki PDO (> php 5.1)
• Lekki silnik będący jedynie interfejsem do obsługi modułów
• Przerzucenie maksymalnej ilości kodu do modułów
• Obsługa wielojęzyczności poprzez moduł gettextowy (pliki *.mo)
• Część prezentacyjna: system szablonów (najprawdopodobniej Smarty)

A teraz zasada działania modułów na przykładzie modułu "aktualności":

• Moduł dostarcza 2 widoki: "lista newsów" oraz "news", a także model pobierający z bazy dane
• Użytkownik tworzy nową gałąź serwisu (np. ROOT/aktualnosci) nadając jej widok "lista newsów"
• Widok "lista newsów" pozwala na dodawanie sobie podstron (np. ROOT/aktualnosci/news1), które mogą korzystać jedynie z widoku "news"
• Każdy widok jest powiązany z plikiem konkretnym plikiem szablonu

Nie bardzo wiem jak rozwiązać uniwersalność pliku szablonu - aby po dodaniu nowego modułu nie trzeba było nic w nim ruszać - aby sam zaaplikował styl użytkownika. Myślę, że spokojnie CSS sobie poradzi - czyli design byłby tworzony jedynie z pliku CSS i obrazków, pliki szablonów byłyby w pewnym sensie podpinane "na sztywno".

Co o tym myślicie?

Nie mam jeszcze zielonego pojęcia jak rozwiązać w taki projekcie obsługę wielu jezyków - tak, żeby można było tłumaczyć bezpośrednio w panelu biorąc pod uwagę to, że niektóre wyrażenia do przetłumaczenia będą w bazie danych, a niektóre już w szablonie.

[Ludvik]

@Ludvik: czy rozumiesz wyraz "przykładowo"?

Dziwnie się składa, że odpowiedź jest twierdząca. Czasami zdarza się człowiekowi nie doczytać, szczególnie o tej porze.

Każdy rodzaj strony musi posiadać następujące pola: tytuł, datę powstania, autora, itp. - treść natomiast może być różna:
- dla newsa: wstęp i pełna treść
- dla produktu w sklepie: opis, cena, fotki, itp.
- itd.

Wszystkie pola "specjalne" w bazie byłyby zapisywane w jednej kolumnie - jako zserializowana tablica

Będziesz miał problem z sortowaniem danych względem pól "specjalnych". Poczytaj temat, do którego adres podał ci Diwi.

A teraz zasada działania modułów na przykładzie modułu "aktualności":

• Moduł dostarcza 2 widoki: "lista newsów" oraz "news", a także model pobierający z bazy dane
• Użytkownik tworzy nową gałąź serwisu (np. ROOT/aktualnosci) nadając jej widok "lista newsów"
• Widok "lista newsów" pozwala na dodawanie sobie podstron (np. ROOT/aktualnosci/news1), które mogą korzystać jedynie z widoku "news"
• Każdy widok jest powiązany z plikiem konkretnym plikiem szablon

Skoro już mówimy o przykładzie, to większość u Ciebie robi widok. Na przykład "pozwala na dodawanie sobie podstron". Przy pisaniu CMS, ciężko będzie bez wzorca MVC. Mimo wszystko podszedł bym do sprawy inaczej, przypisując elementom typy, a nie widoki. Sprawa by była prostsza - widoki by były wymienne, niezależne od siebie, a same elementy były by łatwe do jednoznacznego zidentyfikowania.

[elnino.pl]

Będziesz miał problem z sortowaniem danych względem pól "specjalnych". Poczytaj temat, do którego adres podał ci Diwi.

Racja, rozwiązanie to miało inne plusy, ale już zniknęły...

Skoro już mówimy o przykładzie, to większość u Ciebie robi widok. Na przykład "pozwala na dodawanie sobie podstron". Przy pisaniu CMS, ciężko będzie bez wzorca MVC. Mimo wszystko podszedł bym do sprawy inaczej, przypisując elementom typy, a nie widoki. Sprawa by była prostsza - widoki by były wymienne, niezależne od siebie, a same elementy były by łatwe do jednoznacznego zidentyfikowania.

Czyli tak:
2 rodzaje widoków - content + listing

Dodajemy newsa (wszystkie pola dla niego odpowienie) i wybieramy do niego widok (jeden z dostarczonych przez moduł oznaczonych jako content).

I tu sprawa jest prosta, ale co z listingiem? Dla struktury:
ROOT/news/tytuł_newsa1
ROOT/news/tytuł_newsa2
ROOT/news/tytuł_newsa3
wiadomo, że ROOT/news/ będzie listingiem.

Ale jeśli zechcę dodać na stronie głównej dodatkowo listing? Albo w menu dowolnej innej podstrony?

Chciałbym, żeby z poziomu szablonu można było wywoływać soć takiego:

{module_block module=news order=date limit=5 var=zmienna}

i do zmiennej $zmienna wywalana jest tablica 5 najnowszych newsów (ich dane listingowe). I teraz możemy sobie w szablonie dowolnie to wyświetlić - jako listing, lista punktowana, itp.

Zależy mi jednak, żeby ten blok był generowany dynamicznie, a jednocześnie żeby korzystał ze skryptu, który powołuje do życia aktualny plik szablonu - żeby nie tworzył nowego połączenia z bazą i zapytania tylko po to, żeby pobrać te dane - czy to wykonalne? Chodzi o to, żeby skrypt rozpoznał zanim wywoła szablon to, co będzie w nim potrzebne i przygotuje to. Chyba będzie trzeba dodać pliki konfiguracyjne dla każdego szablonu zawierające listę bloków...