On Mon, 27 Feb 2012 00:10:17 +0100, Marek wrote:

[...]

> Rozumiem, chodzi o to aby CMS dodawał klasę "foo" do elementu w przypadku
> gdy znika jedna kolumna? Jeśli tak, to jest to dość kłopotliwe rozwiązanie.
> W section mamy treść a aside to galeria zdjęć. Inny moduł ją generuje. Tak
> więc moduł od treści nie wie, że galeria będzie pusta w danym przypadku a w
> innym nie. Mogę oczywiście to zmienić ale tak czy owak unikam wstrzykiwania
> przez CMS czegokolwiek do HTML.

Cały kod HTML "wstrzykujesz" CMSem.


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


--
M.G.

do góry

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.

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

Nie są w żadnym przypadku podmieniane nazwy klas CSS bo skąd CMS miałby
wiedzieć na jakie? Nie są wstawiane żadne elementy HTML - ich nazw nie
znajdzesz w oprogramowaniu CMS. 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ć. CMS staje się
wtedy aplikacją dedykwaną konkretnemu serwisowi. Owszem, wtedy jest czasem
trudniej coś ostylować gdy raz jakiś blok pojawia się a innym razem nie.
Zazwyczaj jest to wykonalne, a czasem piszę na forum prosząc o jakieś
koncepcje. Zawsze jest coś za coś.

do góry

Dnia Mon, 27 Feb 2012 01:56:15 +0100, Jordan Szubert napisał(a):

> Dnia 27-02-2012 o 00:18:49 Marek <p...@s...com> napisał(a):
>
>> Dnia Sun, 26 Feb 2012 20:37:25 +0100, Jordan Szubert napisał(a):
>>
>>>
>>> czemu nie :last-child, nie wymagający zamiany kolejności?
>>
>> A jak to miałoby zadziałać? Przy jednym <section> będzie klasa wskazywała
>> na pierwszy element, a przy dwóch - na drugi. Przy jednym elemencie
>> chciałbym mieć szerokość 800px. Prz dwóch, pierwszy 700px, drugi 200px.
>> Jak
>> to zadeklarować?
>
> <div>
> <section>...</section>
> <aside>...</aside>
> </div>
>
> badz
>
> <div>
> <section>...</section>
> </div>
>
> oraz
>
> section {
> float: right;
> width: 700px;
> }
> aside {
> float: right;
> width: 200px;
> }
> div > section:last-child {
> width: 800px;
> }
>
> czemu nie?

Aaahaaa! Sprytne! Dzięki :-) Masz rację. To zadziała. :-)

> w pierwotnych wymaganiach nie bylo nic o dwoch <section/>, 1 <section/>
> oraz 0 lub 1 <aside/>

No nie było. Nie wiedziałem, do której wersji nawiązałeś: pierwotnej mojej
czy kolegów. Stąd niejasność.

do góry

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

> Nie są w żadnym przypadku podmieniane nazwy klas CSS bo skąd CMS miałby
> wiedzieć na jakie? Nie są wstawiane żadne elementy HTML - ich nazw nie
> znajdzesz w oprogramowaniu CMS. Aby podmieniać te składowe kodu, ich nazwy
> musałyby być zaszyte w oprogramowaniu [...]

Nie musiałyby być, w moim cms-ie zrobiłbym tak:
<section [if nie_ma_sekcji_aside]class="foo"[end]>...</section>

i nazwa klasy nie musi leciec do oprogramowania.

--
Tomek

do góry

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.

do góry

On Mon, 27 Feb 2012 10:52:59 +0100, Tomasz Sowa wrote:

> Dnia Mon, 27 Feb 2012 10:32:56 +0100, Marek napisał(a):
>
>> Nie są w żadnym przypadku podmieniane nazwy klas CSS bo skąd CMS miałby
>> wiedzieć na jakie? Nie są wstawiane żadne elementy HTML - ich nazw nie
>> znajdzesz w oprogramowaniu CMS. Aby podmieniać te składowe kodu, ich nazwy
>> musałyby być zaszyte w oprogramowaniu [...]
>
> Nie musiałyby być, w moim cms-ie zrobiłbym tak:
> <section [if nie_ma_sekcji_aside]class="foo"[end]>...</section>
>
> i nazwa klasy nie musi leciec do oprogramowania.

Ale ja odnoszę wrażenie, że właśnie to już jest dla Marka "zaszycie".

--
M.G.

do góry

W dniu 2012-02-27 10:52, Tomasz Sowa pisze:
> Dnia Mon, 27 Feb 2012 10:32:56 +0100, Marek napisał(a):
>
>> Nie są w żadnym przypadku podmieniane nazwy klas CSS bo skąd CMS miałby
>> wiedzieć na jakie? Nie są wstawiane żadne elementy HTML - ich nazw nie
>> znajdzesz w oprogramowaniu CMS. Aby podmieniać te składowe kodu, ich nazwy
>> musałyby być zaszyte w oprogramowaniu [...]
>
> Nie musiałyby być, w moim cms-ie zrobiłbym tak:
> <section [if nie_ma_sekcji_aside]class="foo"[end]>...</section>

Z tego co zrozumiałem to Marek nie ma takiego "wjazdu" w kod HTML. Poza
tym prawdopodobnie moduł sekcji nic nie wie o swoim otoczeniu (bo i po
co) więc ten warunek by nie zadziałał nawet gdyby mógł mieszać w HTMLu.


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

do góry

On Mon, 27 Feb 2012 14:01:47 +0100, Paweł Piskorz wrote:

> W dniu 2012-02-27 10:52, Tomasz Sowa pisze:
>> Dnia Mon, 27 Feb 2012 10:32:56 +0100, Marek napisał(a):
>>
>>> Nie są w żadnym przypadku podmieniane nazwy klas CSS bo skąd CMS miałby
>>> wiedzieć na jakie? Nie są wstawiane żadne elementy HTML - ich nazw nie
>>> znajdzesz w oprogramowaniu CMS. Aby podmieniać te składowe kodu, ich nazwy
>>> musałyby być zaszyte w oprogramowaniu [...]
>>
>> Nie musiałyby być, w moim cms-ie zrobiłbym tak:
>> <section [if nie_ma_sekcji_aside]class="foo"[end]>...</section>
>
> Z tego co zrozumiałem to Marek nie ma takiego "wjazdu" w kod HTML. Poza
> tym prawdopodobnie moduł sekcji nic nie wie o swoim otoczeniu (bo i po
> co) więc ten warunek by nie zadziałał nawet gdyby mógł mieszać w HTMLu.

Jestem ciekaw co to za CMS, bo pluginy powinny mieć dostęp do info na temat
otoczenia. Zresztą musi istnieć jakaś możliwość generowania własnych
zmiennych w szablonach, więc przekazanie flagi nie powinno być problemem.


--
M.G.

do góry

W dniu 2012-02-26 20:37, Jordan Szubert pisze:
> czemu nie :last-child, nie wymagający zamiany kolejności?

Oooo, :last-child to jest pomysł:
<div>
<section>...</section>
<aside>...</aside>
</div>

section {
width:700px;
}

section:last-child {
width:800px;
}

Można też skorzystać z :only-child:
section: {
width:700px;
}

section:only-child {
width:800px;
}

Niestety w obu przypadkach jest założenie, że nic więcej poza tymi dwoma
elementami się nie pojawi w danym divie. No i działa to dopiero od IE9.


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

do góry

On Mon, 27 Feb 2012 14:10:19 +0100, Paweł Piskorz wrote:

[...]

> Niestety w obu przypadkach jest założenie, że nic więcej poza tymi dwoma
> elementami się nie pojawi w danym divie. No i działa to dopiero od IE9.

A skoro zakładamy IE9, to możemy założyć obsługę :nth-last-child

http://www.quirksmode.org/css/nthlastchild.html

--
M.G.

do góry