On Mon, 27 Feb 2012 10:32:56 +0100, Marek wrote:

> Dnia Mon, 27 Feb 2012 08:19:39 +0100, M.G. napisał(a):
>
>> Cały kod HTML "wstrzykujesz" CMSem.
>
> Nie, zupełnie inaczej to realizuję - o tym dalej.

Realizujesz to jak inni, serio.


>>> CMS może jakiś kod HTML zawarty w formatce
>>> powielać itp. aby zachować pełną separację kodu HTML i oprogramowania.
>>
>> Cały kod generowany jest przez CMSa. Frontend jest widokiem, efektem
>> działania tego co zainstalowane i zamodelowane zostało pod spodem. Jak
>> możesz to "odseparować"?
>
> Już wyjaśniam. Mianowicie CMS niczego sam nie generuje poza wstawianiem
> treści z bazy danych. W uproszczeniu do naszych rozważań działa to tak:
> - formatki zawierają wyłącznie kod HTML, JS, CSS, obrazki itp
> - formatki stanowią kod, który da się edytować w edytorach WYSIWYG i
> podglądać w przeglądarkach i sprawdzać validatorami. Nie są to kawałki
> niespójnego kodu, które jakaś logika porządkuje. CMS pracuje więc na
> eleganckim kodzie HTML/XML czy cokolwiek.

Niespójność i elegancja to osobne kwestie. Robisz to co inni - masz
ustalony wynikowy kod frontendu i każesz CMSowi taki kod generować.


> - formatki zawierają markery bloków, które CMS ma powielać (np. sekcja
> newsów to wielokrotnie powielony taki blok HTML)

Czyli CMS generuje HTMLa. Powielenie sekcji to jest generowanie HTMLa.
Wszystko co robi CMS jako wynik swojej pracy, to generowanie HTMLa
(ewentualnie JSONa, RSSa, czegokolwiek co potrzebne), jedyna różnica może
tkwić w tym czy masz kontrolę nad kodem, który generuje (dobry CMS) czy nie
masz (kod "zaszyty" na sztywno, zły CMS, ewentualnie zły moduł).


> - CMS podmienia w takim bloku tylko treść, jakieś ID dokumentów, które mają
> linkować się czy obrazków. Klonuje go tyle razy ile jest newsów (skoro już
> taki przykład dałem). Sam nie generuje żadnego kodu HTML o ile nie jest on
> treścią wprowadzoną przez redaktora.

Czyli CMS generuje HTMLa, w dodatku podmieniając atrybuty elemenentów. Nie
przeszkadza Ci, że zmienia "id" ale przeszkadza, że zmieni "class"?


> Nie są w żadnym przypadku podmieniane nazwy klas CSS bo skąd CMS miałby
> wiedzieć na jakie?

Bo go o tym poinformujesz? Skoro informujesz go o HTMLu, który ma
generować, to możesz go poinformować o atrybutach, które ma generować.


> Nie są wstawiane żadne elementy HTML - ich nazw nie
> znajdzesz w oprogramowaniu CMS.

Znajdziesz je w szablonach, których CMS używa.


> Aby podmieniać te składowe kodu, ich nazwy
> musałyby być zaszyte w oprogramowaniu na stałe a to oznacza brak separacji
> oprogramowania i "widoku" na co sobie nie chcę pozwolić.

To nie oznacza żadnego braku separacji, to jest prawidłowe generowanie
dwóch różnych widoków w dwóch różnych sytuackach. Sytuacja, w której jakaś
porcja danych jest elementem widoku i ma być wyświetlona jest sytuacją inną
niż ta, w której nie jest. Dwa różne widoki.


> CMS staje się
> wtedy aplikacją dedykwaną konkretnemu serwisowi.

CMS jest zawsze aplikacją dedykowaną konkretnemu serwisowi. To nie musi
oznaczać modyfikacji samego CMSa ale jeśli CMS nie dostarcza narzędzi,
które pozwalają na zareagowanie inaczej w dwóch różnych sytuacjach... to
jest jakaś stara Joomla?

Generowanie różnych klas dla różnych widoków jest podstawową praktyką przy
korzystaniu z CMSa, na tym polega "separacja". To dlatego np. Worpdress ma
funkcje generujące klasy dla BODY, które pozwalają ostylować inaczej każdy
widok (stronę, kategorię, taksonomię, post, archiwum, cokolwiek), czy
dodaje klasy typu "current_page_item" jeśli z URLa wynika, że aktualnie
jesteś na danej podstronie.


> Owszem, wtedy jest czasem
> trudniej coś ostylować gdy raz jakiś blok pojawia się a innym razem nie.

Gdy raz jakiś blok się pojawia, a raz nie, to masz do czynienia z dwoma
różnymi widokami. Dostają one dwa różne zestawy danych (co do rodzaju
nawet, nie tylko co do liczby instancji podobnego obiektu), przez co
zmianie ulega widok. A widok to po prostu HTML i cała reszta, więc może
zawierać cokolwiek. Klasy, id, data-cosie.

[...]


--
M.G.