Что предпочтительнее отдавать шаблонам для рендеринга страниц?
Возник вопрос. Есть класс странички, который рендерит шаблон.
Вопрос состоит в том, что предпочтительнее отдать контроллеру в шаблон: подготовленные данные в виде массивов или массив объектов?
Или тут уже от конкретной ситуации зависит?
Мне кажется, что страничка (грубо говоря, контроллер) должна подготовить данные и в удобном виде отдать шаблону. Но в этом я не уверен на 100%, прошу совета.
Ваш вопрос незримо подразумевает возможность исполнения логики в шаблонах.
А давайте на минуточку представим, что в качестве шаблонизатора используется некий вымышленный Dumby, который умеет делать всего три вещи:
- циклы
- условия
- вывод переменной
С одной стороны, логика в шаблонах - грешно. С другой стороны, смотря какая логика.
В данном конкретном случае, мне ничто не должно помешать, как передать массив с готовыми к "употреблению" данными, так и передать массив объектов.
Но тут палка о двух концах получается. Передавать массивы - это не знание какие данные могут быть в нем. Описывать данные в шапке конкретного шаблона?
Модели - точно знаем какие данные можем ожидать. Это точно плюс.
Мне видится выход из ситуации - использование DTO моделей. Но верен ли такой подход?
И честно говоря, не очень понял Ваш вопрос. Если шаблонизатор не поддерживает вызов функций/методов, то зачем такой нужен?
Ну а если по существу, то вывод элемента массива считается за вывод переменной?
@Yakud в непонятных ситуациях я часто прибегаю к рассмотрению предельных случаев, чтобы прочистить голову.
Такой шаблонизатор, конечно, не нужен, но хорошо показывает, как оно по идее должно работать в некотором сферическом мире в вакууме.
Ваш пример с массивами/объектами не очень хороший, поскольку путем несложных телодвижений можно приделать доступ к объекту как у массиву ($myObject['prop1']). Тут вопрос скорее в том, собираетесь ли Вы вызывать какие-то конкретные методы объекта, и что это за методы. Понятно, что геттер-метод и метод, вызывающий модификацию данных объекта - это совсем-совсем идеологически разные сущности.
Про верность подхода... ну, от ситуации зависит, конечно. Простой пример: допустим, в контроллере вы каким-то образом добыли некий список объектов, а в представлении вам железно нужен массив. Идеологически верным (если забыть про arrayable interface) в это ситуации, полагаю, является предварительное преобразование списка в нужный формат на стороне контроллера. Но теперь предположим, что единственное, что происходит в представлении - вывод списка элементов в виде таблицы. Иными словами - for-цикл. И вот в этот момент в голове появляется нехороший червячок, шепчущий: "лишний цикл, убери лишний цикл...". Как бороться с червячком, и надо ли бороться вообще - от Вас зависит.
Идеальный сферический конь, про которого я всегда люблю вспоминать в таких случаях - XSLT-преобразование. Вроде бы все офигенно: формируем xml, передаем, а дальше хоть в браузере рендерить можно, хоть на сервере. Данные как на ладони, вызов критичных методов невозможен, и вроде всё здорово. Но потом оказывается, что на клиенте рендерить xslt - зло, а на сервере - немного нелепо (добыли данные, обернули в xml, преобразовали xslt, отдали... а сразу отрендерить нельзя было?..)
Много букв, да. Сам вот хожу постоянно и мучаюсь вопросами "а как правильно-то?". И хоть бы одна сволочь ответ дала :)
В таком случае, если отдавать объекты, то кто-нибудь может сделать какой-нибудь не самый простой запросик в базу, например. А потом ищи, что там проседает так.
Является ли хорошей альтернативой, так называемые DTO (Data Transfer Object)?
С точки зрения архитектуры - подготовленные данные. Так убудет достигнуто лучшее разделение полномочий, и запросы к БД не будут осуществляться на этапе рендеринга шаблона
С точки зрения удобства разработки АКА программистской лени - объекты все равно пролезают, таща за собой методы, лейзи лоадинг и всю прочую логику модели.