закрепление материала...

[iceman]

закрепление материала...

Все я окончательно запутался...

Что есть MVC?

Что есть компонентный подход?

Например из старой книжки "PHP5 В подлиннике" вычитал пример с гостевой книгой, у меня сформировалось такое мнение:

MVC:
Контроллер - это моя программа, в которой разделен вывод и логика...
если программа простая, то не обязательно разделять Controller и Model, но View всегда разделена.

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

-----------------

теперь спроектируем мини-портал, на котором будут
Новости (http://test.ru/news/)
Статьи (http://test.ru/articles/)
Поиск (http://test.ru/search/)

по MVC нужно 3 контроллера, 3 шаблона, 3 модели

news/index.php (контроллер) - Здесь, Загружаю новости из БД (модель), отдаю данные шаблону.

Но! У сайта есть блоки (left-right-header-footer), например "Облако тегов", здесь мне придется в контроллере news/index.php загружать данные из Модели "Облако тегов", хотя контроллер новостей, а не "облака тегов" и рендерить шаблон с блоком "Облако тегов"

по "Компонентному подходу", все почти так же, разница в идеологии
news/index.html это та же страничка сайта просто с новостями.
т.е. здесь я указываю какие блоки нужны, и подгружаю их.

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

суть топика: Направьте на путь истинный...

 

[Духовность™]

мне придется в контроллере news/index.php загружать данные из Модели "Облако тегов", хотя контроллер новостей, а не "облака тегов"

по этому пункту: эта проблема только на моей памяти 2 раза тут поднималась и к сожалению я так и не понял, как это сделать без говнокода.

Если интересно, почитай: http://phpclub.ru/talk/showthread.php?s=&threadid=112694
http://phpclub.ru/talk/showthread.php?s=&threadid=113307


По второму пункту:

слишком много php вставок в шаблоне

я начинаю думать, что это не самое страшное. намного страшнее будет то, что "придется в контроллере news/index.php загружать данные из Модели "Облако тегов"". Компонентный подход я ни разу не использовал, теперь, думаю, что это самый правильный подход. Шаблон должен быть активным, т.е. вызывать компоненты и забирать у них данные. То, что "слишком много php вставок в шаблоне" - это нисколько не беда. Это будут именно php-вставки, а не логика модели. А вот куда девать логику контроллеров при компонентном подходе - я не знаю.

 

[iceman]

Компонентный подход я ни разу не использовал, теперь, думаю, что это самый правильный подход

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

 

[Духовность™]

тоже так кинулся на него, не поняв что это...

http://dklab.ru/chicken/nablas/16.html - тут у автора твоей книжки вполне приемлимое объяснение (Четвертый способ. Кодовая фраза: «разделяй и властвуй».)

 

[iceman]

Наткнулся на компоненто-ориентированный фреймворк
http://www.xisc.com/

но первый взгляд "какой-то событийно-ориентированный", опять же копаюсь, читаю, изучаю

-~{}~ 09.04.09 12:54:

Контроллер - это моя программа, в которой разделен вывод и логика...

значит, все таки это не так? Контроллер это просто "узел"? как его применять?

 

[Духовность™]

Контроллер это просто "узел"? как его применять?

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

 

[CHEM_Eugene]

Re: закрепление материала...

Автор оригинала: iceman
Все я окончательно запутался...
Что есть MVC?
Что есть компонентный подход?
Например из старой книжки "PHP5 В подлиннике" вычитал пример с гостевой книгой, у меня сформировалось такое мнение:

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

 

[Alexandre]

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

 

[Духовность™]

нормальные книги

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

я ни разу не встретил никакого компонентного подхода

Ты суслика видишь? — Нет. — И я нет. А он есть! (с)

Компонентный подход никак не противоречит MVC. MVC - это абстракция, теория, а не паттерн проектирования завязанный конкретной на реализации.


iceman
Я тему открыл: http://phpclub.ru/talk/showthread.php?s=&threadid=113913&rand=17

 

[CHEM_Eugene]

triumvirat, я считаю книгу Котерова вполне адекватной, она хороша для изучения начал, а потом в принципе и как справочник годится. Нормальная книга.

Просто MVC, если не ошибаюсь в 1979 придумали совсем другие люди и по этому вопросу написано ой как не мало. Стоит обратиться к более ранним источникам информации.

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

 

[iceman]

я так понял свою ошибку:
MVC - это просто "тупо" разделение вывода и логики, склеивание происходит в контроллере... не важно где использовать этот патерн, в "модуле", "плагине" и т.д.

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

 

[korchasa]

Эрм, толи у нас книжки разные...

Компонентный подход это то prado, adept, yii. Т.е. страница бьется на множество отдельных частей, КАЖДАЯ из которых имеет свой контроллер и представление.

Самый большой минус - низкая скорость из-за необходимости хранить и обрабатывать дерево(обычно большое) компонентов.