MVC, методы.

Я бы выбрал джангу и не мучил ЛОР

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

Алсо смарти как шаблонизатор весьма неплох, но кроме шаблонизатора там уже пол-фреймворка наворотили. Я бы не стал использовать.

P.S. Ну а если любишь велосипеды, возьми отдельно ОРМ, отдельно _легкий_ шаблонизатор, отдельно другие нужные компоненты и делай на нем. Хотя профита не вижу.

А че тут думать-то! Бери пхп и не вы******ся!

не знаю, может несколько оффтоп по отношению к теме топика, но я, например, вообще не понимаю профита smarty. в своих view я пишу на альтернативном синтаксисе для php control structures.

ну, пример с потолка:

<?php foreach ($this->employees as $employee): ?>
  <p>
    <?= $employee->name ?>
<?php   if ($employee->loggedIn): ?>
    Вошел в систему
<?php   else: ?>
    Не вошел в систему
<?php   endif ?>
  </p>
<?php endforeach ?>

вот нафига мне смарти? хотя к ZF его можно прикрутить, но у меня никогда такого желания не возникало.

HMVC в kohana смотри

>но я, например, вообще не понимаю профита smarty. в своих view я пишу на альтернативном синтаксисе для php control structures.

Профит в читаемости кода. В том чтобы его мог править не пхп девелопер. Прочитать про 10 структур в смарти может любой резчик, изучать же пхп для него - оверхед. Допустить ошибку в более простом смарти сложнее. Написать нечитаемый код - так же сложнее. Нет явной возможности «по бырику чего то дернуть с базы», т.е. это более жесткое View. А еще у смарти есть мощный strip(да, да не у всех еще гигабит дома).

Кстати: 1. Ты используешь в своем коде short tags, что очень не рекомендуется. 2. Ты не эскейпишь $employee->name, хотя мы и не знаем про его содержимое но такое лучше делать автоматически.

ну «по бырику чего то дернуть с базы» во view — это вобще ахтунг, я даже в контроллере это не стану делать, для этого есть модель.

может быть, где есть разделение девелопер/верстальщик смарти таки имеет смысл.

PS таки да, $this->escape($employee->name)

Какой _легкий_ шаблонизатор вы бы посоветовали? :3

Как-то так http://www.google.com/search?q=fastest|best+php+template+engine

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

Вот только никто не спрашивал, будет ли у него вообще кто-то код править, и умеет ли заказчик вообще пользоваться компьютером. Разделение труда - это дело хорошее, но не всегда требуемое.

Нет явной возможности «по бырику чего то дернуть с базы», т.е. это более жесткое View

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

http://mundogris.wordpress.com/2008/02/05/mvc-not-a-good-architecture-for-web...

>Вот только никто не спрашивал, будет ли у него вообще кто-то код править,

вот только я и не утверждал что это верно для всех людей в мире.

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

MVC как раз запрещает. Его реализации как правило - нет. Перечитайте так же мою фразу еще раз.

http://mundogris.wordpress.com/2008/02/05/mvc-not-a-good-architecture-for-web...

Большое ХА-ХА. Основные тезисы статьи почему MVC не годится для веба, просто перечислю т.к. комментировать просто излишне:

- MVC was designed for window GUIs.

- MVC can handle passive displays but it was meant for active displays.

- MVC assumes that the model (view state) is persistent.

- MVC was designed for a common graphical environment without special encodings.

> вот только я и не утверждал что это верно для всех людей в мире.

Верно, но и не писал, что это нужно в 10% случаев:

но я, например, вообще не понимаю профита smarty

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

- - -

MVC как раз запрещает. Его реализации как правило - нет. Перечитайте так же мою фразу еще раз.

Перечитал еще раз. Невозможность залезть в произвольное место модели ты выдаешь за достоинство (база может быть как полностью моделью с хранимками, так и быть результатом работы оной, возможно кешем, в том числе и специально подготовленным чем-то вроде пререндеренных данных в мемкешде). Ну и посмотри сюда: http://www.garfieldtech.com/blog/mvc-vs-pac

Большое ХА-ХА

http://engineeredweb.com/blog/10/4/its-time-nomvc

комментировать просто излишне

слив засчитан

> its-time-nomvc

Для Ъ:
Почему MVC плох:
- сложен для некоторых хомячков
- не применим во всех случаях жизни

Какой же вывод делает автор? Он делает два вывода. 1) Есть случаи, когда MVC неплох, и 2) «Время сказать нет MVC».

Яркий случай взаимоисключающих параграфов.

Ну а ты simple best world web master!

> http://www.garfieldtech.com/blog/mvc-vs-pac
«In MVC, the View component has direct access to the Model»

Походу, в википедии не про тот MVC пишут.

в своих view я пишу на альтернативном синтаксисе для php control structures.

<?=

Не рекомендуется к использованию

<?php if ($employee->loggedIn): ?>

Это всё хорошо, пока не начнутся конструкции, типа

<a href="<?php echo $this->url()?>">ссылка</a>

Да и банальное

доставляет :)

...

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

>Какой _легкий_ шаблонизатор вы бы посоветовали? :3

Twig

>Сам MVC хоть и разделяет логику и представление, но совершенно не запрещает лазить в базу самостоятельно

Не запрещает. Но это уже будет не MVC, а обычное спагетти с сыром :)

> Не запрещает. Но это уже будет не MVC, а обычное спагетти с сыром :)

Вот я нагенерил 100500 заготовочек html-кода специально для view, мне надо куда-то их положить, дабы потом быстренькой из view подключать сразу готовые куски (получается что-то вроде статики с динамической сборкой). Вопрос: если такие заготовки положить в базу, то чем это будет противоречить оригинальному MVC?

Сам MVC хоть и разделяет логику и представление, но совершенно не запрещает лазить в базу самостоятельно

Не запрещает. Но это уже будет не MVC, а обычное спагетти с сыром

Блин, ну и каша у вас в голове. Будет это MVC.

В MVC модель ничего не должна знать о представлении, но представление может знать о модели. И все. В этом ВСЯ идея MVC.

И таки да, под моделью можно много чего понимать. MVC слишком общее понятие.

Для веба более актуально говорить о трехзвенке. И во вью лучше не пихать хранимые сущности, а специальные модели (DTO).

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

Вида не должно касаться, откуда возьмётся {include $template}, из ФС или из БД. Собственно, даже контроллер об этом может не подозревать.

>В MVC модель ничего не должна знать о представлении, но представление может знать о модели

И что? Как это связано с тем, что я сказал? :)

по ссылке есть чудествй комментарий: http://www.garfieldtech.com/blog/mvc-vs-pac#comment-760 .

сейчас, произнося слово «mvc» нужно уточнять о чем именно хочется сказать, поскольку этот TLA стал использоваться для обозначения разных понятий.

смысл MVC, который придумали для smalltalk, был про разделение концепций представления для пользователя (tool) и бизнес/domain-логики (model). а внутри представления - ввода (controller) и вывода (view). пруфлинк: http://heim.ifi.uio.no/trygver/themes/mvc/mvc-index.html .

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

видимо «разделение дизайна от кода» тоже можно обозвать словами mvc. :)

>сейчас, произнося слово «mvc» нужно уточнять о чем именно хочется сказать

Обычно, всё же, подразумевается разделение систем работы с данными, систем, обрабатывающих запросы и систем, выводящих результат. Точные соотношения и формулировки - да, часто у разных людей и проектов обозначают разные понятия.

в последствии, термин MVC так же стал ассоциироваться с методом разграничения зависимостей

А эта практика полезна в системе с любой идеологией :)

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

Ты говоришь про push модель. Есть еще pull, а так в остальном я согласен.