Считаете ли вы реализации представлений в PHP-фреймворках удобными?

Все популярные PHP-фреймворки сегодня используют собственную реализацию уровня представления, основанную на чистых шаблонах PHP и множестве помощников. Я пробовал некоторые из них и всегда обнаруживал, что такой подход значительно усложняет довольно простые вещи. Например, в формах Zend Framework и разбиении на страницы используются собственные решения для настройки внешнего вида этих элементов. Помощники заново изобретают циклы, обеспечивая также довольно медленные решения, и весь уровень представления, на мой взгляд, не существует как одна часть, но многие его функции делегированы другим частям скрипта. Те же проблемы с конфигурацией возникли в Symfony и генераторе админки, а в Kohana мне пришлось дублировать один и тот же код во всех моих формах. Действительно ли PHP - хороший выбор для уровня представления? Вы также находите эти реализации неудобными или, может быть, почему, несмотря на все эти проблемы, они хороши и не могут быть заменены, например, интеллектуальным механизмом шаблонов (я не имею в виду Smarty :))?


frameworks php view template-engine
person Zyx    schedule 28.03.2009    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Сейчас мне нравится PHP, но, в первую очередь, это язык шаблонов, а не язык программирования общего назначения ни объектно-ориентированный язык. Не борись с этим. Прими это.

Я просмотрел несколько разных фреймворков MVC, таких как Symfony, CakePHP и Zend, и мне трудно пройти мимо примеров. Обычно они такие: «Из этих 17 файлов можно создать программу« Hello world »!» Хм?!?!

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

Я больше поклонник ' рамки без фреймворка. Это на самом деле метод «катить самостоятельно», но я думаю, что он приводит к максимально экономному и чистому конечному результату.

Я так же отношусь к Smarty. Многие люди в SO являются большими поклонниками Smarty, но для меня никогда не было смысла добавлять язык шаблонов к своему ... языку шаблонов.

В конечном итоге я большую часть времени пишу такой PHP-скрипт.

<?
require 'config.h'; // set up constants, DB connections and so on
page_header('My Page'); // page header, site menu and so on
deny_unregistered(); // security
if (/* user submitted page */) {
  $valid = validate_form(/* validation rules */);
  if ($valid === true) {
    // do db changes
    // redirect user ie POST+REDIRECT+GET
  } else {
    // output error messages
  }
}
?>
// display page
<? page_footer(); ?>

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

URL: /index.php?inc=blah

index.php:

<?
require "$inc.php"; // hopefully you sanitize this but so many don't
?>

Я считаю это уродливым, подверженным ошибкам и даже опасным. У меня есть иерархия файлов PHP, которая отражает структуру сайта (с точки зрения меню), где каждая страница является сценарием PHP. Если у них общее поведение, они оба требуют этого (не require_once, который обычно используется в качестве уловки для плохой организации).

Просто, легко, понятно, понятно.

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

person cletus    schedule 28.03.2009

arrow_upward
0
arrow_downward

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

Что мне не нравилось в помощниках просмотра в ZF, так это то, что они обычно делали мой код более раздутым, чем чище. я конкретно говорю о помощнике $ this-> url () :)

person mkoga    schedule 28.03.2009