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.