Создание структуры CMS

[Ragazzo]

Он вернулся *запасаюсь попкорном*

 

[Вурдалак]

она должна быть независима и легко измеряема.

Духовность™, кому она должна? По определению, твои шаблоны в большинстве случаев править будет труднее. В layout ты можешь держать всё общее, как в абстрактном классе. А сейчас для изменения чего-то тебе придётся править 100500 шаблонов и добавлять один и тот же код. Борись с избыточностью, блеять!

 

[vart]

caballero Ну с паяльником не стоят, но делать надо именно мне. Огромное спасибо за такой развернутый ответ.
Если кому интересно:

Я решил подключать модули includ ами (подключать буду точку вхождения модуля - т.е. контроллер). Дальше думаю где создавать объект контроллера (наверно в шаблоне) и как и где вызывать action ы контроллера (наверно в специальном классе например Router).

 

[vart]

Духовность™, кому она должна? По определению, твои шаблоны в большинстве случаев править будет труднее. В layout ты можешь держать всё общее, как в абстрактном классе. А сейчас для изменения чего-то тебе придётся править 100500 шаблонов и добавлять один и тот же код. Борись с избыточностью, блеять!

я походу немного не в теме (хоть ее и я создал) о каком наследовании шаблонов идет речь?

 

[Absinthe]

о каком наследовании шаблонов идет речь?

http://habrahabr.ru/post/23132/

моя идеология такова - верстка - это не программирование. повторяющаяся верстка - это не тоже самое, что и повторяющийся код функции. верстка - это одежда для модуля/контроллера/страницы.

Т.е. говнокодить копипастить нельзя в модели и контроллере, а в виде - можно?
Я не вижу плюсов у этого копипаста. Минусы вижу: сложность поддержки.
Если какая-то страница вдруг должна быть совсем другой - то никто же не стоит с дулом у виска и не говорит "нельзя не наследовать тот шаблон".

 

[AmdY]

какое к чёрту наследование, завёл master темплей и в него либо инклудишь в нужном месте шаблон модуля, либо результат рендеринга этого модуля.
в данном случае наследование это уже оверинженеринг. подождите пока он начнёт wysiwyg вставлять, чтобы он вёрстку нормальную выдавал, чтобы картинки вставлялись.... Чувак думает, что админку писать легче чем переписать весь говносайт на нормальной CMS. Ну-ну.

 

[Вурдалак]

AmdY, а если нужна страница, которая будет отличаться от master template?

 

[AmdY]

показывать другой master template

 

[Absinthe]

AmdY почему оверинженеринг? Если мы указываем кусок вида в виде(где, по сути, ему и место) - это оверинженеринг, а если в контроллере(мастершаблон) - то все окей?

 

[Духовность™]

Духовность™, кому она должна? По определению, твои шаблоны в большинстве случаев править будет труднее. В layout ты можешь держать всё общее, как в абстрактном классе. А сейчас для изменения чего-то тебе придётся править 100500 шаблонов и добавлять один и тот же код. Борись с избыточностью, блеять!

чем их править труднее? что труднее править? у каждой страницы свой целостный шаблон, свой каркас. повторяющиеся куски можно вынести.

в чем причина не хранить каждый шаблон модуля/контроллера отдельно? давайте конкретные примеры. у меня их, к сожалению нет. В любом случае если что-то нужно поправить, search+replace все решают за доли секунд.

 

[Absinthe]

у каждой страницы свой целостный шаблон, свой каркас.

Если надо будет исправить какой-то общий скрипт на странице, тебе придется все файлы менять. При этом вспоминать/исследовать, где одинаково, а где что-то отличается.

повторяющиеся куски можно вынести.

С 1 шаблоном работать проще, чем с нарезкой из него, которые, к тому же, не понятно в каком порядке.

search+replace все решают за доли секунд.

Я понял, для чего подпрограммы в середине прошлого века придумали - не осилили серч/реплейс перфокарт.

 

[Духовность™]

какой-то общий скрипт на странице

живет в файле яваскипта

 

[AmdY]

Absinthe
потому что это требует дополнительного функционала от шаблонизатора. при этом у нас получается жёсткая связьс предком как при ООП-шном наследовании.
Допустим один шаблон для вывода новостей нужно использовать с на двух разных шаблонах (пример - обычная и мобильная версия)

 

[AmdY]

моя идеология такова - верстка - это не программирование. повторяющаяся верстка - это не тоже самое, что и повторяющийся код функции. верстка - это одежда для модуля/контроллера/страницы. она должна быть независима и легко измеряема.

а нафига копипастить, если можно без этого? при этом всё решается одной строчкой.

 

[Духовность™]

все отвалите делаю как хочу

 

[Absinthe]

живет в файле яваскипта

И подключается в общей части.

потому что это требует дополнительного функционала от шаблонизатора.

И что в этом плохого?

при этом у нас получается жёсткая связьс предком как при ООП-шном наследовании.
Допустим один шаблон для вывода новостей нужно использовать с на двух разных шаблонах (пример - обычная и мобильная версия)

Что мешает передавать базовый в качестве параметра(переменная контекста)?

 

[С.]

Один отдельный шаблон отвечает за одну какую-то функциональность (например новости). Не его собачье дело городить шапки/подвалы вокруг себя. Он вообще не должен знать, где его ипользуют: как отдельную страницу, как часть ленты или как вставку в правом верхнем углу.

 

[AmdY]

Что мешает передавать базовый в качестве параметра(переменная контекста)?

Я ждал, тогда мы получаем обратно возврат к моему варианту с мастером, так как в контроллере задаём базовый шаблон. ПРобелу 2 озвучил С.

все отвалите делаю как хочу

Негодяй, вернитесь, я Вам расскажу как делать правильно.

 

[Фанат]

Дальше думаю где создавать объект контроллера (наверное в шаблоне).

Может, не создавать, а вызывать статический метод?
Скажем, у нас страница отображения новости. Помимо текста новости на ней выводится форма авторизации/ссылка на кабинет. Соответственно,

- роутер вызывает контроллер новостей
- который готовит данные
- и передает их во вью
- вью инклюдит основной шаблон
- в котором есть конструкция <?=User::showLoginForm()?>
- класс юзер готовит данные и вызывает вью
- вью готовит подшаблон: включает буфферинг, инклюдит шаблон, получает хтмл и возвращает его

Хотя такие вызовы тоже не слишком кошерно.
Я бы, скорее, делал так

- роутер вызывает контроллер новостей
- который готовит данные
- и передает их во вью
- вью первым делом запускает отдельный контроллер основного шаблона, в котором руками прописан код, который проверяет, определена ли переменная $showLoginForm и если нет, то дергает User::showLoginForm()
- класс юзер готовит данные и вызывает вью
- вью готовит подшаблон: открывает трай, включает буфферинг, инклюдит шаблон, закрывает трай, получает хтмл(или фигу) и возвращает полученное
- вью инклюдит основной шаблон
- в котором есть конструкция <?=$showLoginForm?> ( как и <?=$newsTitle?> <?=$newsText?> ...)
- и заполняет его данными.

В итоге шаблон занимается только выводом данных и ничем больше.


В случае же блочного шаблонизатора вызовом соответствующих модулей может заниматься обработчик view, "выпаршивая" вызовы из шаблона.

 

[vart]

Нет такая структура мне не подойдет. Ведь количество модулей на странице шаблона не ограничено. Если в адресной строке нет обращения к конкретному /index/ то вызываются контроллеры этих модулей с action = view (т.е. просто отображение). Иначе /index/controller/action/params мы вызываем уже конкретный action модуля (а все остальные по прежнему просто отображаются