Это плохая идея, чтобы вернуть HTML-код из функции или метода? - PullRequest
2 голосов
/ 21 декабря 2009

У меня есть идея:

когда кто-то звонит mysite.com/layer1/layer2/something, тогда я хочу запустить действие под названием something. Это действие - просто файл в каталоге actions, который содержит функцию. Эта функция принимает некоторые параметры контекста и должна возвращать вывод HTML. Этот вывод, который входит в переменную, будет затем перенесен в основной шаблон, и, наконец, небольшой фреймворк выбросит сразу весь вывод html.

Теперь я не знаю, если это хороший или плохой дизайн - возвращать большие объемы HTML-кода из функции или метода?

Ответы [ 5 ]

4 голосов
/ 21 декабря 2009

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

3 голосов
/ 21 декабря 2009

Нет ничего плохого в возврате HTML из функции при условии, что эта функция находится на уровне представления, и вы поддерживаете хорошее разделение логики бизнес / контроллер / представление.

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

<div id="Outer">
  <?= $content ?>
  <p class="Inner">
    <?= $more_content ?>
  </p>
</div>

В отличие от:

$buffer .= '<div id="Outer">' . $content .
           '<p class="Inner">' . $more_content .
           '</p></div>';

По крайней мере, первый способ позволяет вашей IDE / редактору выполнять правильную подсветку синтаксиса.

2 голосов
/ 21 декабря 2009

Вообще говоря, нет, это не так. Вы должны выделить какой-то шаблон, а затем вернуть обработанный шаблон.

Например:

В вашем файле действий:

public function iterateList($data, $template = 'default.php')
{
   /* do stuff processing data
   keeping it super simple we'll say $data = array(
     0=> array('title'=>'HEllo World', 'content'=>'lorem ipsum')
     1 => array('title' => 'Look ma im iterating' => 'cool')
   );
   */
   ob_start();
   include($template);
   return ob_get_clean();
}

в вашем default.php Обратите внимание, что все в локальной области функции, включая это, доступно здесь, т.е. $ Данных

<ul>
<?php foreach($data as $item):?>
  <li>
    <h3><?php echo $item['title']; ?></h3>
    <p><?php echo $item['content']; ?></p>
  </li>
<?php endforeach; ?>
</ul>

Таким образом, вам никогда не придется изменять действие для обновления структуры, вы просто изменяете аргументы, передаваемые функции и шаблону ...

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

Прочитайте шаблоны MVC и Front Controller и / или Page Controller.

1 голос
/ 22 декабря 2009

В MVC Frameworks вы часто найдете множество ответов на этот вопрос. Вот два принципа, которые я пытаюсь соблюдать, в отношении этого.

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

2) Данные, обрабатываемые системой, должны использоваться во многих формах. Если ваши данные могут понадобиться для других целей, помимо отображения, то позже вы можете столкнуться с необходимостью рефакторинга или даже дублирования кода, когда поймете, что вам нужен «Ted Developer» в «Developer, Ted», «Ted Developer» формы '' и 'Ted', и ваша функция возвращает только одну из трех.

1 голос
/ 21 декабря 2009

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

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

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

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