Хорошие статьи по шаблонам в PHP

Вурдалак · 17 Июн 2012

Фанат, где именно у тебя происходит экранирование? Не в контроллере, не в шаблоне. Где?

Absinthe · 17 Июн 2012

Вурдалак экранирование по хорошему должно быть в шаблоне, но на уровне шаблонизатора, чтобы не писать это явно. И неэкранированные данные должны идти так: <?= noescape($data) ?>

Вурдалак · 17 Июн 2012

Absinthe, туда-сюда гонять экранированный/оригинальный текст?

Sufir · 17 Июн 2012

Фанат написал(а):
Не очень понял, что возвращает find(). Объект класса Good? Но это разве не модель? А почему тогда присваивается переменной $view? Откуда в $view->good берется метод getDescription()?

Ну, я упростил всё по максимуму. Должо быть вот так (для ZF):

PHP:

class GoodController extends Zend_Controller_Action {
  public function indexAction() {
    $id = $this->getRequest()->->getParam('id');
    $this->view->good = Mapper_Goods::find($id); // возвращает Model_Good
    // или $this->view->goods = Mapper_Goods::fetchAll() - возвращает массив содержащий Model_Good
  }
}

Это уже практически рабочий код. Соответственно $view->good - это объект Model_Good.

Фанат написал(а):

Лично я считаю, что модели делать во вью нечего.
поэтому

PHP:

Good {
  public static find() {}
}

PHP:

GoodController {
  $id = $request->getId;
  $data = Good::find($id);
  $data['link'] = $this->makeUrl($id);
  $data['pic'] = $this->makePic($id);
  $view->setTemplate('good.tpl.php');
  $view->setRaw('description');
  return $data;
}

PHP:

<title><?= $title ?></title>
<body>
  <div id="good-<?= $id ?>">
    <a href=<?=$link?>><img src=<?=$pic?>></a>
    <span><?= $title ?></span>
    <span><?= $price ?></span>
    <p>
        <?=$description ?>
    </p>
  </div>
</body>

А, ну, вот к тому всё и свелось, что во вью нечего делать объектам. Там должны быть только скалярные типы, ну, и может быть array. И без шаблонизатора никак. А, что плохого в объектах во вью?

Вурдалак · 17 Июн 2012

Sufir написал(а):
А, что плохого в объектах во вью?

По двум причинам:

Они не вписываются в теорию Фанат'а (нет возможности красиво автоматически экранировать данные из getter'ов средствами pure PHP).
Можно сделать что-то, не предназначенное виду, типа $user->setName('XXX')->save()

Но ведь можно же и в контроллере написать

PHP:

echo '<b>Hello!</b>';

— не пишут же. Так не пишите и во View всякую ерунду.

Объект во View таскать удобно.

Sufir · 17 Июн 2012

Можно сделать что-то, не предназначенное виду, типа $user->setName('XXX')->save()

Ну, у модели нет метода save, это метод маппера:

PHP:

$good = new Model_Goods;
$good->setTitle('XXX');
$mapper = new Mapper_Goods;
$mapper->save($good);

В данном случае модель Goods представляет конкретную сущность предметной области - "товар" и ничем таким не занимается. "Товар" не знает не только где его хранить будут, в mySQL, в PostgreSQL, MongoDB, XML или CSV, но и что вообще будут. Он знает, что у него есть название, цена и скидка и что с ними делать.
Это конечно частный случай. Но, в целом мне тоже, кажется очень удобным передавать во вью объект представляющий сущность, а не массив или переменные. Да и с какой стати мне должно придти в голову сохранять модель в виде, да и откуда там брать данные для сохранения?..

Вурдалак · 17 Июн 2012

Sufir написал(а):
Ну, у модели нет метода save

Это дело 10-е, в ActiveRecord есть, например. Не суть.

Absinthe · 17 Июн 2012

Absinthe, туда-сюда гонять экранированный/оригинальный текст?

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

Вурдалак · 17 Июн 2012

Absinthe, PHP вам не предоставляет других возможностей.

С. · 17 Июн 2012

Absinthe написал(а):
Мне затея кажется глупой, особенно учитывая необходимость рекурсивного прогона в неведомых структурах данных.

Как это неведомых? Модель четко знает, какие данные и для чего она генерит в соответствиии с ТЗ. Так что не надо ничего никуда взад-вперед эскейпить и рекурсивно проходить.

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

Absinthe · 17 Июн 2012

Absinthe, PHP вам не предоставляет других возможностей.

Ну раньше про наследование шаблонов так же говорили

Как это неведомых? Модель четко знает, какие данные и для чего она генерит в соответствиии с ТЗ. Так что не надо ничего никуда взад-вперед эскейпить и рекурсивно проходить.

Мой шаблонизатор читать ТЗ неумеет. Научите?

С. · 17 Июн 2012

А модель умеет?

Absinthe · 17 Июн 2012

С. нет. С чего модели что-то знать о верстке?
Предлагаешь в ней определить безопасные поля и опасные, и дергать их через магические методы?

Mols · 17 Июн 2012

Модель которая должна экранировать данные для отображения - это просто прорыв.
Пора наверное господину С. нобеля вручить.

З.Ы.
В целом кстати топик не касается взаимодействия моделль- вид.
Он касается" шаблонизаторы или нативный пхп".

флоппик · 17 Июн 2012

Господа, давайте будем терпимее к чужому мнению.

С. · 17 Июн 2012

Absinthe написал(а):
С. нет. С чего модели что-то знать о верстке?
Предлагаешь в ней определить безопасные поля и опасные, и дергать их через магические методы?

Не надо передергивать. Вопрос был "модель-ТЗ", а не "модель-верстка".

Возьмем например задачу выдачу сообщения пользователе на форуме. Разрешать ли тэги в нем, решает модель. Фильтрует вредные тэги -- модель. А решать, эсекейпить ли сообщение перед выдачей будет шаблон? С какого хрена?

Mols · 17 Июн 2012

С. написал(а):
Возьмем например задачу выдачу сообщения пользователе на форуме. Разрешать ли тэги в нем, решает модель. Фильтрует вредные тэги -- модель. А решать, эсекейпить ли сообщение перед выдачей будет шаблон? С какого хрена?

с такого.
Проверка и фильтрация - это обработка данных и это как раз работа модели.
А эскейпинг - это задача отображения.
Кроме всего прочего зависящая от конкретной реализации отображения.
Здесь уже как минимум 4 разных варианта было перечислено. HTML, JSON, YAML, PDF.
Можете добавить AMF, CSV, Excel и всё что угодно.
Какого хрена модель должна думать о том, в каком именно виде её данные идут потребителю?

С. · 17 Июн 2012

Да представь, это модель решает будет ли мое сообщение выглядеть так или так. Это вопрос контента, а не отображения.

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

Mols · 17 Июн 2012

ну хз.
Для меня это дико.
И выглядит как излишняя связанность.
Но давайте забьем на этот вопрос)))
Здесь таки речь не про модель-вид, а про шаблонизатор-натинвый_пхп.

Лично мне всегда хватало нативного пыха, но насколько я помню, твиг оставил о себе весьма приятное впечатление.
Правда проблема в том, что я его реально не юзал. Только доку читал.
И что-то там было весьма интересное... вроде какого-то наследования хитрого.
Может кто-то сказать что нить интересное о твиге?
(кроме того, что там эскейп автоматом))))

С. · 17 Июн 2012

Это выглядит дико, потому что на уровне ТЗ в модель ошибочно внедряются элементы отображения. Например в том же редакторе сообщений традиционные это пережиток безMVCнного прошлого. По правильному там должно быть <ins> - сильное выделение и не очень сильное выделение (от вообще даже в HTML давно отказались).

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

Хорошие статьи по шаблонам в PHP

Продвинутый новичок

жожо

Продвинутый новичок

Я не волшебник, я только учусь

Продвинутый новичок

Я не волшебник, я только учусь

Продвинутый новичок

жожо

Продвинутый новичок

Продвинутый новичок

жожо

Продвинутый новичок

жожо

Новичок

promotor fidei

Продвинутый новичок

Новичок

Продвинутый новичок

Новичок

Продвинутый новичок