Rozważam wykorzystanie OPT 2 w CMS-ie, ale w taki sposób, aby można było go zastąpić pierwotną klasą Content (wykorzystującą szablony w formacie PHP). Tylko mogą wystąpić problemy z kompatybilnością. Czy ktoś używa tego systemu szablonów?

1. W klasie Content zdefiniowałem metody: addScript() i addCSS(). Można je ewentualnie przenieść do klasy OPT i zmodyfikować.
2. Są też istotne różnice w implementacji. Zobacz: kod klasy Content.
3. Przykłady: zmienne $title i $head, tworzenie referencji (ominięcie $this->data), informacja
4. Zamierzam jeszcze wprowadzić możliwość użycia wielu szablonów z poziomu logiki skryptu, może przez Content::addFile().

Ewentualnie mogę użyć OPT tylko jako kompilatora szablonów, choć to jest niezgodne z założeniami tej biblioteki. Z drugiej strony można pokonać te różnice, dokonując trochę zmian w kodzie.

Dlatego pytam - czy warto użyć OPT 2 w CMS-ie?

Druga sprawa dotyczy skór w systemie CMS. Wszystkich szablonów (plików prezentacji modułów) będzie dużo (ok. 50). Zawartość większości z nich raczej nie zmieni się w innych skórkach, dlatego nie ma sensu ich powielać. Czy wystarczy, aby każda skórka zawierała tylko pliki CSS oraz grafikę? Rozważam jeszcze dołączenie głównego layoutu serwisu (body.php) i panelu admina - ale w ten sposób znów nie utrudnię wykorzystania systemów szablonów? Może proponujecie inaczej rozwiązać ten problem?

PS. Odwiedzający mogą zmienić domyślną skórkę na inną.

Odpowiem w punktach:
1. Kto używa OPT - hmmm... są tacy hardkorowcy, co się biorą za wersje rozwojowe bez czekania choćby na betę .
2. Z każdym systemem szablonów będziesz mieć istotne różnice w implementacji. Jeśli już, może spróbuj dostosować klasę Content?
3. Podepnij jako bloki.
4. OPT2 wspiera takie coś, choć dokładne wykorzystanie zależy od użytego trybu (w trybie XML możesz jedynie zagnieździć jeden szablon w innym).

Tak naprawdę Twój problem brzmi: czy warto użyć systemu szablonów w CMS-ie, bo na podobne przeszkody napotkasz w zdecydowanej większości dostępnych bibliotek. Generalnie gdy ja chcę zachować możliwość wymiany, staram się od razu dostosować jeden interfejs do drugiego, a nie robię dwa osobne, zupełnie do siebie niepasujące i później myślę, co dalej z tym fantem zrobić . Moja rada jest następująca: nie cuduj z 1234 zmiennymi trzymanymi w 543 różnych miejscach i wymagających 768 różnych kodów do ich obsługi, w zależności od kontekstu. Zrób jedno, ale żeby pasowało do wszystkiego - czemuś takiemu ma właśnie służyć pole data w OPT oraz metody assign() itd. (nawiasem mówiąc przypisywanie przez referencję jest w zestawie).

Moja odpowiedź na to pytanie jest więc następująca: przyzwoity system szablonów da się dopasować do chyba każdej implementacji. Jest to kwestia przestrzegania pewnych konwencji, niekombinowania jak koń pod górę oraz umiejętności wykorzystania dostępnych narzędzi. Robiłem CMS-y na OPT (poprzedniej wersji), sprawowały się znakomicie. W każdym razie na pewno wprowadzenie szkieletu strony czy panelu admina nie będzie dla niego przeszkodą .

Ad. skórek - jasne, że mogą składać się wyłącznie ze stylu CSS i grafiki, ale musisz być świadom, że w takim połączeniu masz trochę mniejsze możliwości i jesteś uzależniony od jednej konkretnej struktury kodu HTML. Jeżeli nie możesz czegoś na niej osiągnąć, wtedy masz problem. Spróbuj podzielić skórki na dwie kategorie: proste, wyłącznie zmieniające CSS i grafikę innego stylu, lub pełne, zmieniające wszystko.

Temat porządnego wykorzystania szablonów zająłby spory artykuł i niewykluczone, że taki niebawem napiszę - jeden post to trochę za mało. Jeśli zaś chodzi o OPTv2, to obecnie znacznie lepiej będzie, jeżeli weźmiesz wersję pierwszą. Dwójka jest w fazie rozwojowej, tzn. formalnie zmianie może ulec dosłownie wszystko i nie masz żadnej gwarancji, że coś będzie działać w 100%, albo nawet że w ogóle będzie działać, jak powinno, nie wspominając już o braku dokumentacji. Testowałem go dotąd wyłącznie w "warunkach laboratoryjnych", ale w obecnym stadium rozwoju, szczególnie jeżeli nie miałeś dotąd do czynienia z systemami szablonów, odradziłbym tę wersję.