Dnia Mon, 27 Feb 2012 11:06:12 +0100, M.G. napisał(a):

>> Nie, zupełnie inaczej to realizuję - o tym dalej.
>
> Realizujesz to jak inni, serio.

Ok :-)

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

Poniekąd oczywiście, że tak. Starałem się jednak sprecyzować co znaczy dla
mnie "generowanie". Może inaczej to wyjaśnię. W/g mojej definicji
"generowanie" zachodzi wtedy gdy w kodzie np. PHP znajdziemy coś w stylu:

print("<div>");

Czyli generowanie (w mojej definicji) to jest tworzenie kodu jakiego
fragmentów nie było w formatce.

> 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ł).

To kwestie leksykalne. Powyżej zdefiniowałem to co miałem na myśli.

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

Dokładnie trafiłeś w sedno. Nie przeszkadza mi kostrukcja w kodzie HTML:

<a href="dokument_TU_WSTAW_ID.html">link do mojego dokumentu</a>

a bardzo mi przeszkadza:

<p class="TU_WSTAW_KLASĘ">bla bla</p>

Gdy w przeglądarce czy edytorze WYSIWYG popatrzysz na kod drugi, to
niepoprawnie go wyświetli gdyż nie ma klasy w CSS o nazwie
"TU_WSTAW_KLASĘ". Znacznik umieszczony w linku nie przeszkadza.

>> 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ć.

Osobiście stronię od takich rozwiązań. Bardzo trudno poruszać się po kodzie
obfitującym w "widoczne inaczej" sekcje. To tak jak programowanie w kodzie
maszynowym zamiast w językach wyższego rzędu.

>
> CMS jest zawsze aplikacją dedykowaną konkretnemu serwisowi.

U mnie nigdy tak nie jest. Praktycznie wszędzie CMS jest identyczny.
Zmieniają się tylko zainstalowane lub włączone moduły. O funkcjonalności
decyduje formatka HTML. Ona poza szatą graficzną zawera specjalne markery
(nie zaburzające validacji ani wyglądu) sterujące CMSem.

> 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?

Nie w tym rzecz. CMS jest autorski. Mie ma potrzeby aby moduł np.
generujący menu wiedział o tym, że ma reagować inaczej gdy dokument
wyświetlany na tej samej stronie ma obrazki lub nie ma - czyli pojawi się
lub nie kolumna <aside> w naszym przypadku. Takie sprawy rozwiązuje się za
pomocą CSS. Jordan zaproponował zgrabne rozwiązanie - zerknij tam. Jestem
zwolennikiem przejrzystości kodowania tak aby rozwiązania zastosowane przez
ich autora były samokomentujące się. Dlatego wstawianie znaczników w
miejsce klas psuje taką koncepcję.

> 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.

A nie lepiej podmienić plik CSS gdy potrzebujemy coś inaczej mieć
ostylowane lub zarządzać mediami na poziomie CSS? Chyba tylko wtedy
istnieje potrzeba zmiany stylu (dla drukarki inaczej dla ekranu inaczej).
Kwestię ostylowania podstron też prosto można rozwiązać bez używania
"wstrzykiwanych" klas. Wystarczy dla podstron zbudować inną formatkę z
innymi klasami. Wtedy ktoś kto grzebie w naszym kodzie zobaczy jak wyglądać
będzie taka podstrona bez uruchamiania CMS i łatwo będzie mógł ja
zmodyfikować. Gdy natomiast CMS będzie podrzucał w locie jakąś klasę to
marnie widzę szansę na zlokalizowanie kodu bez konsultacji z jego autorem.

>> 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.

Może nie do końca rozumiem tą koncepcję. Co znaczy "widok" w tym przypadku?
Skąd jest on brany i jakie są kryteria wyłonienia właściwego? Jeśli to
jakiś moduł programowy go określa - wydaje mi się niepotrzebnym tworzenie
takiego modułu jeśli CSS to załatwia. Wydaje mi się to szalenie złożoną
ideą do prostych zadań. Załóżmy, że mamy dokument z 3 kolumnami, z których
każda z nich może pojawić się lub nie. Czy to oznacza, że musimy
wygenerować 6 widoków spełniających wszelkie kombinacje? Czyli liczba
widoków może dążyć do nieskończoności gdy kolumn jest więcej.