компонентный подход, мвс и шаблоны

grigori

( ͡° ͜ʖ ͡°)
Команда форума
new wave :)

triumvirat, в этой теме ты нескольких ключевых местах сам себе противоречишь
>процесс получения этих данных лишает контроллер универсальности
цена универсальности - объем кода, потеря производительности, гибкости и поддерживаемости
>мои контроллеры имеют вид классов с методами по 200 строк!
а теперь будет еще больше

Кстати, по строчке в файле " if (Request::isPost()) {" я предполагаю, что одним скриптом ты и форму выводишь, и запрос обрабатываешь.
Попробуй начать с того, что обработчики каждого события писать в отдельных скриптах?

Код:
<body ....>
<?
// контроллер новостей
$nc = new News_Controller();
$nc->run('view_news'); // вызвали какой-то метод контроллера новостей 
$this->addData($nc->getData());
это результат компиляции шаблона или сам шаблон?
по-моему, вызов классов и методов с параметрами - это уже и есть контроллер
... говнокаша из HTML с PHP?


>>подход "активные шаблоны" - очень спорный
>чем?
Есть вопрос целесообразности.
Во многих CMS "активные шаблоны" на псевдо-языке вызывают модули, которые отрисовывают блоки. Только они не лежат не в корне сайта.
Это удобно для визиток, форумов, "супер-порталов" и т.п.

Есть системы, где отображение - 5% объема работы (у меня это финансовые системы). На одной странице выводится одна таблица или одна форма, остальное статика (или почти).
Активные шаблоны тут сильно усложнят жизнь.
 

Духовность™

Продвинутый новичок
по-моему, это ... говнокаша из HTML+PHP
это были нереализованные наброски. да и где ТАМ говнокаша? 3 строчки PHP в шаблоне - это говнокаша?

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

grigori

( ͡° ͜ʖ ͡°)
Команда форума
>3 строчки PHP в шаблоне - это говнокаша?
сначала я ошибся в выражении и подправил - это вопрос
 

atv

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

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

цена универсальности - объем кода, потеря производительности, гибкости и поддерживаемости
объём кода - согласен, потеря производительности - согласен, но никак не потеря гибкости и поддерживаемости.

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

atv

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

Часть бизнес условий касается сохранения данных, ограничения данных. Другая часть может касаться представления данных. Третья часть может касаться ограничения доступа к данным. Всё это бизнес логика, продиктованная условиями бизнеса.
 

Lightning

Трудоголик
atv
Извини, но мне кажется, что это бред какой-то.
Дай мне ссылку, где эти термины объясняются подобным образом, я почитаю.
И что такое тогда доменная логика? Логика, которая навязывается доменом? :)
 

С.

Продвинутый новичок
Lightning, с терминологией конечно проблемы, но вот тебе простой пример: выдать в таблице отрицательные значения красным, положительные - черным. Это бизнес логика или логика представления? Ответ совсем не однозначный. Можно в шаблоне прописать if ($value<0), а можно с массивом чисел передавать соответствующие цвета из модели. Оба варианта не идеальны.
 

AmdY

Пью пиво
Команда форума
виюха может ПОЛУЧАТЬ данные из модели, виьха может вызывать контроллер и точка. не нужно путать view и template, в mvc как раз view.
 

Lightning

Трудоголик
С.
но вот тебе простой пример: выдать в таблице отрицательные значения красным, положительные - черным. Это бизнес логика или логика представления? Ответ совсем не однозначный. Можно в шаблоне прописать if ($value<0), а можно с массивом чисел передавать соответствующие цвета из модели. Оба варианта не идеальны.
Спасибо за пример. Два варианта решения, которые ты привел, действительно неидеальные (с точки зрения полного разделения бизнес логики и логики представления).
Бизнес логика должна знать какое число отрицательное, а какое положительное, а логика представления знать, что есть два вида чисел, одни нужно выделить красным, другие - черным. Значит в модели определяем какие числа отрицательные, какие положительные и передаем в представление соответствующие параметры.
Никаких if( $value < 0 ) в шаблоне. Никаких цветов в модели.
В шаблоне например может быть
PHP:
<?
if( $item[ 'selected' ] ) {
    ?><span class="red"><?
}else {
    ?><span class="normal"><?
}
?>
<?= $item[ 'value' ] ?></span>
Хотя, конечно, из-за такого пшика и дергаться особо нечего. Я бы наверное просто прописал в шаблоне if ( $value < 0 ). Однако, давайте рассмотрим ту же ситуацию на более сложном примере: Выделить в таблице красным числа, которые являются округленными до тысячных коэффициентами Фурье для функции f(x)=lg(e^2x). Тут уже точно лучше разделить логику так как я описал выше.

-~{}~ 26.06.09 22:09:

Чувствую сейчас мне начнут говорить, что я привел нереальный пример...Отвечу сразу: суть от этого не меняется :)

-~{}~ 26.06.09 22:10:

виьха может вызывать контроллер
В Web-приложении это происходит не явно.
 

AmdY

Пью пиво
Команда форума
Lightning
явно:
ты нажимаешь ссылку, тем самым обращаешься к контроллеру
хэлперы, это тоже кастрированные контроллеры
ну и полноценный вызов контроллера в активном шаблоне ( {forward url="news/block/lastNews/"} )

по вашему примеру советую третий вариант
<span class="<?= view_get_class($item[ 'value' ]) ?>"><?= $item[ 'value' ] ?></span>
как раз убрали логику в отдельный контроллер(хэлпер) и провели рефакторинг.
 

Lightning

Трудоголик
явно:
ты нажимаешь ссылку, тем самым обращаешься к контроллеру
Ну если это явно... :)
хэлперы, это тоже кастрированные контроллеры
Какого фига?
(Хотя лучше не отвечай)
по вашему примеру советую третий вариант
<span class="<?= view_get_class($item[ 'value' ]) ?>"><?= $item[ 'value' ] ?></span>
как раз убрали логику в отдельный контроллер(хэлпер) и провели рефакторинг.
Зачем отдельный хелпер? Чтобы размазывать бизнес логику? Чем плох мой вариант?

Ладно, обсуждать эту тему на форуме - гиблое дело.
 

atv

Новичок
Lightning, читай Бизнес-логика

Бизнес-логика — это реализация правил и ограничений автоматизируемых операций. Является синонимом термина «Логика предметной области» (Domain Logic).
Что из того что я сказал, противоречит этому определению? Если в бизнес правилах написано "раскрасить данные в зависимости от следующих условий" то что это?

И что такое тогда доменная логика?
Читай выше "Является синонимом термина «Логика предметной области»"

Логика, которая навязывается доменом?
"Извини, но мне кажется, что это бред какой-то."

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

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

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Lightning
извини за придирку, но "действительно неидеальные" - слитно

мне одному кажется сказаное atv и Lightning китайской грамотой и спором тупоконечников с остроконечниками?
 

AmdY

Пью пиво
Команда форума
Lightning
я предпочитаю максимальную декомпозицию задачи, тогда контролы легко можно реиспользовать в пределах проекта или в другом проекте или даже подсасывать напрямую ajax запросом. хэлпер от обычного контрола отличается тем, что для вызова проделывается минимальный путь, без роутинга, проверки связаных контролов и т.д.
Зачем отдельный хелпер? Чтобы размазывать бизнес логику? Чем плох мой вариант?
зачем? я писал ещё в предыдущем посте ну и + выглядит гламурнее в шаблоне.
 

tf

крылья рулят
grigori, нее нормально про ТС забыли и хорошо)))
 

С.

Продвинутый новичок
Lightning, данный конкретный пример ты решил правильно. Обрати внимание на суть решения: ты просто $item['red'] заменил на $item['selected'] с последующей обратной заменой в шаблоне. Но в реальных, гораздо более сложных случаях, такой однозначной замены не всегда сделаешь. Кроме этого обрати внимание на тенденцию: номенклатура данных, передаваемых из модели в шаблон, обрастает дополнительными атрибутами чисто вьюшного характера.

Вот еще один пример. Имеются данные в виде дерева. Нужно выдать их в виде таблицы (двумерной матрицы) с соответствующими colspan'ами и пр. Вопрос: отдавать в шаблон классическое дерево и дать шаблону "расправить" его в матрицу или воссоздать образ матрицы в модели и в шаблоне тупо ее отрисовать? Не забыть про разные раскраски данных, которые тоже могут понадобиться (как в первом примере).
 

nerezus

Вселенский отказник
atv А что ты скажешь про Delphi for PHP? ) Интересно =)
 
Сверху