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.