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

В итоге получилась ТАКАЯ каша, что сейчас стало очевидно: дальнейшее развитие проекта требует просто-таки колоссальных затрат. Код приходится править во многих местах, вставки некоторых простых элементов (например, валидация) превращаются в муку.

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

MVC. Думаю, что если уж переходить, то на какую-то выработанную сообществом модель. Пытаюсь уложить в голове страницы своего проекта на эту модель и что-то пока не укладывается.

Вот и вопрос: допустим, на странице есть блок вывода курса валют, блок стоимости топлива и блок заголовков новостей по выбранной тематике.
Как эту страницу увязать с моделью мвц? Ведь получается, что для создания этой страницы "трудятся" целых три контроллера и вьюхи: топливо, курсы валют и новости.

Как в таком случае строить правильную архитектуру MVC? Не хочу строить очередные костыли и грабли у себя на сайте, а понять, как реализуются подобные вещи правильно.

Мне нравится идея единого входа (с удовольствием откажусь от тучи рерайт правил в хтаксес), далее парсится урл и передается определенному контроллеру вместе с параметром, если есть. Но вот как быть, если страница собирается из нескольких блоков? Какова логика построения такой страницы в модели MVC? Это первый вопрос

Второй вопрос касается вида. Как грамотно и по правилам модели мвц построить представления, если к примеру, для использования одного блока в хидер надо включить джаваскрипт, который нужен только для части функционала и на определенных страницах?
Т.е. у меня есть логика. И для представления, допустим, картинок - я использую джейкарусель. Смысл этот джс включать во все страницы, если он только на странице просмотра фоток? И вот, модель выбирает нужные данные, обрабатывает и наконец-то данные попадают в вид. В виде есть пара дивов, куда эти данные в виде переменных попадают. Но как добавить в хидер джс? Правильно, я имею в виду.
Предусматривает ли данная модель что-то типа "хуков", как в друпале, когда можно изменить что-то, что делается другой частью функционала?

Вот если я это пойму - тут же начну переход на модель MVC

Для начала просто разделите логику и отображение. php-код - в *.php файлы, html код - в html шаблоны. Так вы выделите вторую букву аббревиатуры MVC
потом, что что осталось в php файлах разделите на код, который обрабатывает запросы пользователя и код, который оперирует данными. В результате получите контроллер(ы) и модель(и).
совсем необязательно все распихивать по классам. можно и функциями обойтись. как удобнее будет на этапе освоения.
если вы сможете разделить вашу "кашу" на логические блоки, понимание MVC придет.
тут наверное ничего сложного. Просто формируем отдельные части страницы в переменные, а выводим их не сразу, а все вместе в конце работы скрипта.
Например переменная $header будет в себе содержать массив строк с метатегами, подключениями скриптов и стилей.
тогда при генерации страницы с каруселью мы добавим в эту переменную элемент
$header[]='<script src="carousel.js"></script>';
а в самом конце скрипта сделаем что-то вроде
echo implode("\n",$header) . $body;

модель ничего не предусматривает. Как закодируешь так и будет.
А вместо дебильных хуков в ООП есть наследование и преопределене функций

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

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

Вроде год спустя понял данный код (конечно с перерывами, но все же )
Теперь возник порос как можно организовать модульность в данной системе???
и еще вожможность выполнения ajax запросов для вывода основного контента, то бишь зашел в категорию и уже только подгружаешь материалы ajax, не обходя вызов метода render

vlom
Если поняли, то в чем трудность? Создайте, к примеру, некое ajax-действие для требуемого контроллера, в нем обрабатывайте запрос. Ответ отдавайте через тот же json к примеру.
Как сделать ajax-запрос - уверен, сложностей не возникнет.
А модульность - это как уже Вы организуете. Как построите архитектуру Вашего приложения, так и будет. Этот учебный код - не панацея, а всего лишь краткий пример. Можете считать это очень начальным введением хотя бы в Zend Framework (рекомендую посмотреть именно в его сторону, там есть ответы на большинство вопросов, возникающих после начального осмысления вещей, подобных тем, что подаются в данном уроке).

с аяксом понял что делать, спасибо
вот с модульностю возникнут проблеммы


не поверишь самому смешно, уже почти год работаю в веб студии, и складывается впечатление аля программист

vlom
Не очень понял, к чему Вы, но думаю - Вы на верном пути. Успехов.

да к тому что толком не хрена не понимаю толком

Кто нибудь собрал этого монстра?
Я и со старыми блоками и с исправленными.
Не выходит каменный цветок...

В уроке присутствует достаточно подробное описание - и приведены все листинги. Если Вы пробовали что-то, то опишите что - а так же, что конкретно не получилось и какой результат был получен.

EuGen, у меня есть несколько вопросов по организации кода.

Вот значит предствим, что есть контроллер по работе с пользователями - Controller_User, в нем есть действия. Часть действий направлена на отображение форм - например метод newuserAction, который просто отображает форму создания нового юзера. Как организовать подклассы View? Базовыей View и дочерний View_User c методом View_newuser?

Второй вопрос. Если так то как быть с данными передаваемыми от контроллера к виду? Пусть в контроллере запрашиваются данные например о списке всех юзеров, и о колличестве сообщений (вообщем несколько ассоциативных масивов в результате) как передать их Виду? Нельзя же Вид сделать дочерними классами конструкторам?!

И еще вопрос. Вот получил я в контроллере данные о пользователях но их перед отображением нужно отформатировать, условия вывода в шаблон добавить, изображения обернуть в тэг img и так далее... где это делать? не в контроллере ведь?

Спасибо.

Для этого существует свойство $view базового контроллера, оно отвечает за текущее представление и может (должно для этих целей) использоваться в контроллере:

Далее,

Зачем их организовывать? В контроллере достаточно вызвать рендеринг соответствующего шаблона:

Далее,

Разумеется. Это нужно делать в представлении, которое будет рендериться в соответствующем действии контроллера.

Тогда я запутался а где тогда это?

И по поводу передачи данных представлению, а если несколько ассоциативных массивов? все в один массив запихивать?

представление=вид?

EuGen, и всё же, где выполнять операции подготовки данных к выводу если есть только базовый Вид с методом рендерингра, а вызывается он прямо из контроллера? Для каждого контроллера - свои операции! В самом шаблоне?