Smarty & загрузка и старт PHP контроллера

[ggfdsfds]

Добрый день.

Есть проект с использованием SMARTY.
На сайте один раз инициализируется объект SMARTY и в каждую страницу поставляются данные о:

- [assign] данные страницы ($page) - id,name,parent_page_id.seo_keywords,seo_desctioption,content_text)
- [assign] данные о текущем авторизованном пользователе ($user)

И теперь самое интересное: - подгрузка данных в шаблон - например вывести список новостей реализована через плагин {dataget className="newModel" runFuntion="main">

class newModel{}{

function main()}

// select * from news
// здесь в итоге происходит [assign]

}

}

Таким образом весь проект (шаблон утыкан этим {dataGet} - плагином.
Это нормальная ситуация?

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

 

[ggfdsfds]

Вот нашел похожий пример - как это не правильно помоему "упихивать" вот такие выборки и поставщики в шаблон?
Или не прав где-то?
Потом же сам не разберешься и запутаешься.

 

[AnrDaemon]

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

 

[Absinthe]

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

Эти фразы друг другу противоречат. Шаблоны тоже должны содержать логику. Логику отображения.

 

[hell0w0rd]

Однако ТС жесть творит и его надо остановить)
ggfdsfds, ты должен в контроллере дергать модельки и тянуть данные, а дальше их передавать в шаблон.
По хорошему в контроллере также не должно быть логики запросов к базе, а просто вызов методов, например $postRepository->getByUser($user) и тд.

 

[AmdY]

hell0w0rd, ой, да нормальный способ, почему бы не тащить данные из модели непосредственно во вьюхе? это удобно и читабельнее, главное что есть сама моделька и логика забора данных инкапсулируется в ней.

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

 

[AnrDaemon]

Эти фразы друг другу противоречат. Шаблоны тоже должны содержать логику. Логику отображения.

Ну, мы то с вами друг друга поняли. А ТС надо было дать по мозгам, а то, видимо, без подзатыльника они у него не включаются.

AmdY тоже дело говорит, кстати.

 

[hell0w0rd]

AmdY, ты точно говоришь о коде во втором сообщении?

 

[AmdY]

hell0w0rd, ага. я считаю это вполне допустимо в некоторых проектах или их частях и сам не стесняюсь иногда пользоваться и тащить данные непосредственно во вьюхе, в обход контроллера.

 

[keltanas]

AmdY, я, конечно, и сам так делал, но это больше похоже на гавнокод )) Сейчас больше по душе более "чистый" подход, имхо. Начал пробовать - понравилось.
Симфа из коробки реализует.

 

[Absinthe]

Делайте скопы, чтобы из вида модели за них дергать.
А вот проксирование данных из модели в вид через контроллер уже зачастую попахивает.

 

[keltanas]

Absinthe, а обычно данные из модели в вид через что передаешь?

 

[Absinthe]

Есть хорошее правило: передавать в вид максимум два набора данных.
Остальные вещи можно получать прямо в виде, к примеру Book::topBooks() (это scope), и их уже итерировать. Нет смысла получать это в контроллере.
Вид может напрямую обращаться к модели в MVC.

 

[keltanas]

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

 

[AmdY]

keltanas, давай конструктивнее. Подход с подтаскиваением простых данных в шаблоне даёт:
1. Читабельность и наглядность, т.к. сразу видно откуда данные берутся.
2. Не надо лишних движений с проксированием данных через контроллер.
3. Удобное кэширование блоков
4. Удобство модификаций шаблонов.
5. отсутствие лишних сущностей и знаний вроде грамотной разбивки на блоки и зависимости между ними.
6. Это MVC-шно

 

[keltanas]

AmdY, ок
1. Читабельность и наглядность ни сколько не хуже, если не лучше
2. Нужны лишние действия для создания скоупа - то же, что и создание контроллера. Блок можно тянуть из соседнего экшена того же контроллера, который создал и саму страницу
3. ESI по умолчанию подразумевает удобное кеширование блоков
4. Для каждого блока отдельный шаблон без лишнего кода, полный reusable любого блока - куда удобнее?
5. Сущности и знания те же самые, только вместо разбивки на блоки получаем лапшу. В ESI никакой зависимости между блоками.
6. Аналогично.
7. Блоки можно тестировать отдельно от остальной страницы, при чем в том числе в зависимости от прав пользователей
8. Инвалидация кеша хоть по времени жизни, хоть по хешу контента
9. При необходимости, блок можно подтянуть аяксом

 

[keltanas]

AmdY, суть-то не в том, конструктивно или не конструктивно. Все эти высосанные из пальца доказательства выеденного яйца не стоят.
Потому что если это будет делать программист Вася Пупкин стоимостью 25 т.р. в месяц на проекте, о котором через месяц все забудут, то мне будет абсолютно все равно, что он там напишет. Пусть хоть SQL-запросы в шаблоне фигачит. Насрать.
Если делаешь сам для себя, то будешь делать так чтобы еще и эстетического удовольствия получить. Благо все инструменты готовы и лежат под рукой.

Так что просто ничего больше не остается, как троллить всяких категоричных граждан, когда они в бутылку лезут ))

 

[Absinthe]

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

Ты так говоришь, как будто это плохо, а контроллеры с 100500 переменными - хорошо.
Есть даже инспекции IDE, которые ругаются, когда ты передаешь шаблонизатору более 2 переменных через контроллер, который о них знать не должен в силу того, что он контроллер.

 

[keltanas]

Absinthe, ну где, где я написал про 100500 переменных в контроллере?

 

[Absinthe]

Absinthe, ну где, где я написал про 100500 переменных в контроллере?

А сколько их передавать из контроллера допустимо?
В моем примере мы обращаемся к модели из вида. Это нормально. Этим данным в контроллере делать нечего.
Как ты предлагаешь их получать в виде? Виджет делать?