W dniu 2010-11-14 04:18, Michał Gancarski pisze:
> W takim razie nie rozumiem w czym problem, a zwłaszcza nie rozumiem pisania
> o "wstrzykiwaniu kodu przez CMS". Ostatecznie kontrolujesz co "wstrzykuje".

No w tym, że wstrzykuję trzecią (środkową kolumnę). Wiem, że ją
wstrzykuje czasem a czasem nie. Zależy od tego co redaktor postanowi a
nie ja. Wiedza o tym fakcie niczego nie zmienia przecież. Moim zadaniem
jako webmastera jest być przygotowanym na to zdarzenie a nie go
zabraniać. Sam ten mechanizm stworzyłem i nie chce go sobie blokować.

Mało tego, zakładając hipotetycznie, że powinienem zrezygnować z tej
funkcjonalności: powód tej rezygnacji też mi się słaby wydaje (czyli
konieczność użycia float:right do realizacji tej funkcji i w
konsekwencji zmiana kolejności występowania w kodzie treści). Chciałeś
przykład layout, w którym trzeba przestawić kolejność kolumn więc dałem.

> "Dostawienia" tzn.? W trakcie projektowania tak wyszło, czy może nagle po
> roku okazało się, że ona tam ma być?

Nie, od samego początku było założone, ze ta kolumna tam będzie LUB nie
będzie.

> Najwygodniej komu?

Najwygodniej w sensie technologicznym. A za przyjęte rozwiązanie
webmaster, czyli ja odpowiada :-) No bo przecież nie klient odpowiada a
nikogo innego nie ma w tym łańcuszku :-)

> Poza tym nadal piszesz o layoucie w oderwaniu od tego co
> w tym dokumencie się tak naprawdę znajduje.
> CMS WYSIWYG?

Nie. Nie dopuszczam w każdym razie aby redaktor umieszczał kod HTML w
treści aby uniknąć zaburzenia semantycznej struktury dokumentu itp. Sam
w każdym bądź razie nie ma możliwości tworzenia kolumn. Podziału
kolumnowego w pewnym sensie dokonuje automat - nie wdając się w detale
(ale jednak wdaję się poniżej czytając co napisałeś). W jaki sposób to
się dzieje - określa webmaster.

> W trakcie normalnego funkcjonowania strony (a nie na etapie
> jej projektowania) to co najmniej rzadkość, nie mówiąc już o zazwyczaj
> kulejących implementacjach.
> Oddawanie takiej kontroli użytkownikowi jest
> wręcz niebezpieczne.

Nie wiem co masz na myśli mówiąc rzadkość. Załóżmy, że w lewej kolumnie
mamy nawigację, w prawej stałe sekcje jak newsy itp. Środkowa pojawia
się okazjonalnie gdy są jakieś szczególne wydarzenia: promocje towaru w
sklepie itp. Przypuszczam, że oddanie użytkownikowi kontroli w postaci
zaznaczenia checkboxa przy produkcie, że jest promowany nie oznacza de
facto "oddania kontroli" w omawianym rozumieniu.


> Jednym z ważniejszych elementów szkolenia redaktorów
> strony jest IMHO określenie zakresu modyfikacji, które będą mogli
> wprowadzać i wyjaśnienie czemu one są tak ograniczone. Redaktor nie robi
> składu, redaktor wrzuca treść.

I tak jest. Redaktor w moim CMS robi jeszcze parę rzeczy więcej:
"konfiguruje" treść. Chodzi o włączanie i wyłączanie pewnych opcji przy
danym dokumencie, które sterują jego wyświetlaniem czy zachowaniem się.
Np. opcja "promocja na stronie głównej" spowoduje automatyczne powstanie
środkowej kolumny.

> Jeśli zmiany w layoucie mogą następować
> zmiany tak znaczące jak układ kolumn, to trzeba raczej starać się to
> przewidzieć wcześniej.

I jest to w 100% przewidziane i zaprojektowanie.

>> Nie wspomnę o
>> tym, że jeśli CSS ulegać będzie zmianom to należy zapomnieć o
>> cach'eowaniu przez przeglądarki tego.
>
> Znów - zanim nie podasz konkretnego przykładu, np. podając link czy
> wskazując o jakim CMSie mówimy, to pozostajemy w sferze ogółów. Zmienność
> CSSa też nie oznacza braku cachowania.

Ufff... jeszcze i to widzę, że będziemy drobiazgowo rozpatrywać. Ok,
dobra. A więc zmienność CSS musi skutkować wyłączeniem lub ograniczeniem
cache'owania CSS dla przeglądarek - a więc niepotrzebnie powiększone
transfery. Jeśli zakładamy, że CSS w każdej chwili może zostać
zmodyfikowany, to nie może on mieć nagłówka Expires ustawianego daleko w
przyszłość. W przeciwnym razie przeglądarka nawet nie spyta serwera o to
czy jest nowsza wersja CSS i wyświetli nową treść ze starym CSS.

> Elementy stałe można wyrzucić do
> osobnego pliku, o ile będzie to w ogóle konieczne. "Zmienność" taka jak
> pojawienie się co pewien czas dodatkowej kolumny zazwyczaj możliwa jest do
> osiągnięcia przez dodanie jakiejś klasy odpowiedniemu elementowi i
> dopisanie stylu w dokładnie tym samym pliku CSS, który był użyty do tej
> pory.

To prawda. I jak tak postępuję. Nie mam potrzeby tworzenia dodatkowych
plików CSS. Lewej i środkowej kolumnie robię jedną klasę z float:left, a
prawej z float:right (w konsekwencji przestawiając tym samym kolejność
występowania w HTMLu tej kolumny). Mam stałe CSS, mogę je sobie
cache'ować swobodnie a jedyną niedogodnością jest to, że jakieś
urządzenie mobilne z upośledzoną przeglądarką w złym miejscu wyświetli
kolumnę. Mam rację?

Jednakże ja osobiście jestem przeciwnikiem modyfikowania CSS
dynamicznie. W tej chwili przerabiamy tylko jakiś konkretny przypadek. W
rzeczywistości więcej takich sytuacji zdarza się. Jestem zwolennikiem
(jak napisałem) statycznego CSS i jedynie HTML może być dynamicznie
generowany.


>> To kolejna wada takiego podejścia.
>> A jak zacznę ze stylami inline'owymi to w ogóle sieczka kodowa powstanie.
>
> To może zacznij klasami?

No jak klasami? Musiałbym namnożyć ich gdybym każdą możliwą kombinację
miał oklasować (np. różne szerokości marginesów w przypadku gdy coś
występuje lub nie). Nie ma takiej potrzeby moim zdaniem. Po to jest
float:right aby go używać. Prawda? :-)