Использовать представления или не использовать представления

Question

Мне кажется, что сейчас я вовлечен в дискуссию с другим программистом по этому проекту, который считает, что у представлений нет никаких достоинств. Он предлагает систему, в которой PHP выглядит примерно так:

$draw = new Draw;
$nav = $draw->wideHeaderBox().
$draw->left().
    $draw->image().
        Image::get($image,60,array('id'=>'header_image')).
    $draw->imageEnd().
$draw->leftEnd().
$draw->left(10).
    '<div id="header_text">'.
        self::defaultSectionText().
    '</div>'.
$draw->leftEnd().

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

Answer 1

HTML-экономия времени полезна, но она полезна только тогда, когда она интуитивно понятна и проста для понимания. Необходимость создания экземпляра new Draw звучит не совсем естественно. Кроме того, wideHeaderBox и left будут иметь значение только для тех, кто глубоко знает систему. А что, если - это редизайн, как ваши коллеги по музыке? Что если wideHeaderBox станет очень узким? Измените ли вы разметку (и стили, предположительно), генерируемые методом PHP, но оставите очень неточное имя метода для вызова кода?

Если вы, ребята, просто имеете для использования генерации HTML, вы должны использовать его с вкраплениями в файлах представления, и вы должны использовать его там, где это действительно необходимо / полезно, например что-то вроде этого:

HTML::link("Wikipedia", "http://en.wikipedia.org");
HTML::bulleted_list(array(
    HTML::list_item("Dogs"),
    HTML::list_item("Cats"),
    HTML::list_item("Armadillos")
));

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

Answer 2

Мне всегда намного проще работать напрямую с html. Существует еще один слой абстракции (html -> фактическая веб-страница / функция php -> html -> фактическая веб-страница), с которым вы можете работать, а затем просто работаете в HTML.

Я действительно думаю, что «просто нужно изменить это в одном месте» вещь не будет работать в этом случае. Это потому, что они будут так много раз, когда вы захотите изменить вывод функции, но только в одном месте. Конечно, вы можете использовать аргументы, но вскоре вы получите несколько функций с дюжиной аргументов. Тьфу.

Имейте в виду, что языки / системы шаблонов часто позволяют включать суб-шаблоны, что позволяет использовать несколько блоков HTML многократного использования.

Суть в том, что если бы я только начинал в вашей компании и видел такой код везде, моей первой мыслью было бы: «Черт возьми! Снова нужна новая работа. '

Answer 3

Я делал что-то подобное в прошлом, и это была пустая трата времени. Например, вам нужно написать обертки для всего, что вы уже можете использовать с HTML, и вы забудете некоторые вещи. Когда вам нужно что-то изменить в макете, вы подумаете: «Стреляй, я забыл об этом… теперь я должен кодировать другой метод или добавить другой параметр».

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

Answer 4

Это выглядит довольно многословно и трудно следовать честно, а часть кода выглядит так, как будто это очень много информации макета.

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

Если мысль о сохранении 2 файлов для этого слишком сложна, попробуйте разделить элементы на часть «Сбор данных» и часть «Отображение», чтобы получить большинство преимуществ без увеличения количества файлов, которые вы надо управлять.

Answer 5

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

Я бы предложил использовать больше шаблонного дизайна. Сделайте всю свою бизнес-логику в PHP, настройте все переменные, которые нужны вашей странице. Затем просто сделайте так, чтобы ваша разметка страницы ссылалась на эти переменные (и не имела никакого отношения к бизнес-логике).

Ты смотрел на ум? http://smarty.php.net