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

Question

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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