W dniu 2012-02-27 14:08, M.G. pisze:
> Jestem ciekaw co to za CMS, bo pluginy powinny mieć dostęp do info na temat
> otoczenia.

MZ jeżeli moduł ma kilka różnych wariantów, to powinna istnieć możliwość
wyboru danego wariantu. Jeżeli by robił warunki w szablonie modułu w
zależności od tego kogo ma za sąsiada to już za rok będzie miał masę
ifów, każdy do innego serwisu.
Tylko czy szerokość modułu jest tutaj takim wariantem? To by było ciut
bez sensu, bo np. ten sam moduł tekstowy może być użyty w artykule, w
prawej kolumnie a także na stronie 404.

> Zresztą musi istnieć jakaś możliwość generowania własnych
> zmiennych w szablonach, więc przekazanie flagi nie powinno być problemem.

Przekazanie flagi pewnie nie jest problemem, zaś jej ustawienie to dla
niego sporo zmian. Przypuszczam że ma tak, iż klient sobie po prostu
włącza/wyłącza dany moduł (w przeciwieństwie do np. wybierania przy
tworzeniu podstrony czy to będzie artykuł z galerią czy bez), więc
dodawanie ręczne odpada, bo klient najzwyczajniej zapomni :)


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry

On Mon, 27 Feb 2012 14:32:21 +0100, Paweł Piskorz wrote:

> W dniu 2012-02-27 14:08, M.G. pisze:
>> Jestem ciekaw co to za CMS, bo pluginy powinny mieć dostęp do info na temat
>> otoczenia.
>
> MZ jeżeli moduł ma kilka różnych wariantów, to powinna istnieć możliwość
> wyboru danego wariantu. Jeżeli by robił warunki w szablonie modułu w
> zależności od tego kogo ma za sąsiada to już za rok będzie miał masę
> ifów, każdy do innego serwisu.

No ale na tym poziomie właśnie serwisy się różnią. Może ja nie rozumiem
tutaj słowa "moduł" ale dla mnie to jest jednostka funkcjonalna, co w żaden
sposób nie determinuje generowanego przez nią kodu. Ja bym się wręcz
spodziewał pełnej kontroli nad kodem wypluwanym przez CMSa, generując
widoki w zależności od sytuacji i pobierając z niego info o stanie
środowiska dla zadanego requestu. To byłoby dla mnie budowanie "szablonów"
dla danego serwisu. Coś, co jest customowe tak czy siak. Totalnie odrzuca
mnie sytuacja, w której o HTMLu wynikającym z działania jakiegoś modułu
definiuje tylko i wyłącznie moduł.


> Tylko czy szerokość modułu jest tutaj takim wariantem? To by było ciut
> bez sensu, bo np. ten sam moduł tekstowy może być użyty w artykule, w
> prawej kolumnie a także na stronie 404.

Chyba naprawdę inaczej rozumiemy "moduł" :-).


>> Zresztą musi istnieć jakaś możliwość generowania własnych
>> zmiennych w szablonach, więc przekazanie flagi nie powinno być problemem.
>
> Przekazanie flagi pewnie nie jest problemem, zaś jej ustawienie to dla
> niego sporo zmian.

Hm, ale jakich? Tzn. nie wyobrażam sobie, że nie mogę się dowiedzieć czy
dany request wypluwa przykładowo jakieś newsy czy nie.


> Przypuszczam że ma tak, iż klient sobie po prostu
> włącza/wyłącza dany moduł (w przeciwieństwie do np. wybierania przy
> tworzeniu podstrony czy to będzie artykuł z galerią czy bez), więc
> dodawanie ręczne odpada, bo klient najzwyczajniej zapomni :)

OK, chyba jestem skażony Wordpressem.


--
M.G.

do góry

Dnia Sun, 26 Feb 2012 11:46:56 +0100, Marek napisał(a):

> Sekcja <aside> może nie pojawiać się w kodzie HTML lecz nie musi (CMS ją
> moze wygenerować lub nie). Chciałbym aby w przypadku gdy nie ma <aside>
> ustawić szerokość <section> na np. 800px. Czy da się to jakoś zadeklarować
> w CSS?

aside { width : 200px; }
section { width : 900px; }
section + aside { width : 700px; }

Też kiedyś to niepotrzebnie komplikowałem ;)

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

On Mon, 27 Feb 2012 17:11:23 +0100, Borys Pogoreło wrote:

> Dnia Sun, 26 Feb 2012 11:46:56 +0100, Marek napisał(a):
>
>> Sekcja <aside> może nie pojawiać się w kodzie HTML lecz nie musi (CMS ją
>> moze wygenerować lub nie). Chciałbym aby w przypadku gdy nie ma <aside>
>> ustawić szerokość <section> na np. 800px. Czy da się to jakoś zadeklarować
>> w CSS?
>
> aside { width : 200px; }
> section { width : 900px; }
> section + aside { width : 700px; }
>
> Też kiedyś to niepotrzebnie komplikowałem ;)

A nie psuje się w IE8?


--
M.G.

do góry

Dnia Mon, 27 Feb 2012 17:16:17 +0100, M.G. napisał(a):

>> aside { width : 200px; }
>> section { width : 900px; }
>> section + aside { width : 700px; }
>>
>> Też kiedyś to niepotrzebnie komplikowałem ;)
>
> A nie psuje się w IE8?

Selektor + obsługuje nawet IE7.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

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.

do góry

Dnia Mon, 27 Feb 2012 17:11:23 +0100, Borys Pogoreło napisał(a):

>> Sekcja <aside> może nie pojawiać się w kodzie HTML lecz nie musi (CMS ją
>> moze wygenerować lub nie). Chciałbym aby w przypadku gdy nie ma <aside>
>> ustawić szerokość <section> na np. 800px. Czy da się to jakoś zadeklarować
>> w CSS?
>
> aside { width : 200px; }
> section { width : 900px; }
> section + aside { width : 700px; }
>
> Też kiedyś to niepotrzebnie komplikowałem ;)

Pisząc tu liczyłem na to, że ktoś przetarł szlaki :-)
Jednakże wydaje mi się, że to nie zadziała. Szerokość section ma się
zmieniać w zależności od obecności lub nie sekcji aside. A tu uzależniasz
szerokość aside jeśli jest poprzedzona przez section lub nie jest. Czyli
dokładnie w drugą stronę niż potrzebuję.

Czyli leśli section + aside => section zmienia szerokość

do góry

Dnia Mon, 27 Feb 2012 22:32:03 +0100, Marek napisał(a):

> Jednakże wydaje mi się, że to nie zadziała. Szerokość section ma się
> zmieniać w zależności od obecności lub nie sekcji aside. A tu uzależniasz
> szerokość aside jeśli jest poprzedzona przez section lub nie jest. Czyli
> dokładnie w drugą stronę niż potrzebuję.

To zmień kolejność i floatuj w drugą stronę, w czym problem?

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

Dnia Tue, 28 Feb 2012 00:14:02 +0100, Borys Pogoreło napisał(a):

> Dnia Mon, 27 Feb 2012 22:32:03 +0100, Marek napisał(a):
>
>> Jednakże wydaje mi się, że to nie zadziała. Szerokość section ma się
>> zmieniać w zależności od obecności lub nie sekcji aside. A tu uzależniasz
>> szerokość aside jeśli jest poprzedzona przez section lub nie jest. Czyli
>> dokładnie w drugą stronę niż potrzebuję.
>
> To zmień kolejność i floatuj w drugą stronę, w czym problem?

O rany. Doradziłeś mi (kolejne) rozwiązanie, ja znalazłem w nim mankament i
go skomentowałem. Jordan zaproponował ciekawe rozwiązanie na bazie CSS bez
dokonywania zmian w kodzie HTML. Więc temat jest zamknięty, co nie oznacza,
że dalsze propozycje nie są dla mnie ciekawe. Mogą się przydać w
przyszłości.

do góry

Dnia Tue, 28 Feb 2012 10:21:29 +0100, Marek napisał(a):

>> To zmień kolejność i floatuj w drugą stronę, w czym problem?
>
> O rany. Doradziłeś mi (kolejne) rozwiązanie, ja znalazłem w nim mankament i
> go skomentowałem. Jordan zaproponował ciekawe rozwiązanie na bazie CSS bez
> dokonywania zmian w kodzie HTML. Więc temat jest zamknięty, (...)

... do czasu, aż nie będziesz potrzebował podobnego rozwiązania dla układu
trzykolumnowego. Wtedy :last-child nie da rady (który też nie jest zbyt
lubiany przez starsze wersje IE), a wersja z selektorem + bez problemu.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry