On Mon, 27 Feb 2012 22:20:34 +0100, Marek wrote:

[...]

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

Niby w jaki sposób wyświetli go niepoprawnie? I dlaczego w CSSie nie ma
stylu dla tej klasy?


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

Nie rozumiem co tu napisałeś. Podgląd HTMLa w przeglądarce nie działa? :-)


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

Co to jest "formatka HTML"? Czy dobrze rozumiem, że nie możecie w pełni w
szablonach decydować o HTMLu odpowiedzialnym np. za nawigację? To wygląda
na pieruńsko niewygodną w wielu CMSach rzeczy czyli brak możliwości pełnego
decydowania o generowanym HTMLu. Nie wszystko da się załatwić CSSem.


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

Ten wątek udowadnia, że taka potrzeba istnieje :-)


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

To jest rozwiązanie tylko jednego specyficznego problemu, a takich napotyka
się dziesiątki. CMS w ogóle nie powinien dyktować HTMLa (może go proponować
ale nie powinien o nim decydować). Idealnie - powinien udostępniać
struktury danych i API, które pozwala wyciągnąć z niego w dowolnym miejscu
dowolnego szablonu dowolny zbiór informacji na temat wprowadzonej do niego
treści. Wordpress w dużym stopniu to np. robi. Możesz generować nawigację
jego funkcjami (co jest zapewne odpowiednikiem "modułu" w Waszym CMSie) ale
możesz go zapytać o strukturę zawierającą info o wybranych podstronach i
wygenerować nawigację jak chcesz. Częściową, całkowitą, zależną od sytuacji
itp. Z HTMLem, o którym w pełni decydujesz. Za pomocą tej samej struktury
zresztą możesz np. stworzyć breadcrumbsy.


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

Jest ciężko, skoro zacząłeś ten wątek. Klasy to jest narzędzie, którego
należy używać, a nie unikać. Od tego są. Jedna klasa załatwia cały ten
wątek, wszystkie te sztuczki i obchodzenie za pomocą fikuśnych selektorów.
Zmień trochę layout, a okaże się, że pojawi się kolejny problem. Tymczasem
gdy masz dużo różnych klas, masz dużo "wieszaków" na style. Stąd tak
cholernie podoba mi się np. Wordpressowa funkcja body_class();


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

Ale jakiego kodu? Zawsze widzisz generowany HTML, niezależnie od tego jak
wygenerowany został. I stylujesz ten HTML jak chcesz. Z klasą czy bez.


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

I od tego masz dodatkową klasę (np. <body class="columns-2">), by sobie móc
ostylować różne warianty.


--
M.G.