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

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

1 голос
/ 28 марта 2009

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

Ответы [ 2 ]

0 голосов
/ 28 марта 2009

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

Я смотрел на несколько разных MVC-фреймворков, таких как Symfony, CakePHP и Zend, и мне было тяжело пройти мимо примеров. Как правило, они «из этих 17 файлов вы можете создать программу« Hello world »!» А?!?! * * 1005

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

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

Я чувствую то же самое в отношении 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. Если у них общее поведение, они оба требуют его ( not require_once , который обычно используется как взлом для плохой организации).

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

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

0 голосов
/ 28 марта 2009

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

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

...