Очередное столкновение логики представления с логикой приложения.

[Фанат]

все эти ваши дудовые рыдания с левелами происходят от одного гигантского заблуждения.
что МОЖНО разделить логику и представление.
а её разделить нельзя.
А вы, в стремлении достичь недостижимого, городите системы всё сложнее и сложнее. В которых уже сами перестаёте что либо понимать.

За что люблю пхп - за простоту.

 

[HEm]

последний мессадж - самый важный в этом топике
(не то чтобы там было недостижимое, но затраты начинают превосходить доходы)

 

[Domovoj]

Автор оригинала: Фанат
все эти ваши дудовые рыдания с левелами происходят от одного гигантского заблуждения.
что МОЖНО разделить логику и представление.
а её разделить нельзя.
А вы, в стремлении достичь недостижимого, городите системы всё сложнее и сложнее. В которых уже сами перестаёте что либо понимать.

За что люблю пхп - за простоту.

Похоже мы просто говорим о разных вещах. Если подумать, до даже стандартный подход (php файл + tpl файл) может быть 3х уровневым:

# Уровень 1

/**
* Выборка данных из базы
*/
function select($start, $count) {
.....
}

# Уровень 2

$list = select(10, 20);
$smarty->assign('list', $list)
$smarty->display('product list');

{* Уровень 3 *}
{section name=a loop=$list}
....
{/section}

Вобщем, похоже это просто перефразировака на объекты того, что ранее было сказано про подготовку данных вне tpl-файлов.

Подумал ещё раз... вопрос мой первый был неверным и к данной теме практически не относится, хоть её и затрагивает (столкновение логик). А скорее относится к теме "организация кода вне файлов-шаблонов". Это просто один из вариантов вынести логику за пределы tpl-файлов, чтобы они были более читабельны, и их легче было править.

-~{}~ 20.05.05 16:59:

Автор оригинала: Фанат
все эти ваши дудовые рыдания с левелами происходят от одного гигантского заблуждения.
что МОЖНО разделить логику и представление.
а её разделить нельзя.

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

 

[syfisher]

Насчет 3 фаз:
Two Step View Pattern по классификации Фаулера.

 

[Нечто]

Скажу нечто само собой разумеющееся:

все эти ваши дудовые рыдания с левелами происходят от одного гигантского заблуждения.
что МОЖНО разделить логику и представление.
а её разделить нельзя.

Вообще-то, разделение вводится не для "просто логики" и "просто представления", а для логики представления и бизнес-логики. Последнее вполне реально, ибо разбивка на колонки есть задача вывода (представления), а бизнес логика - получение и обработка данных.

 

[ONK]

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

Я отношу к бизнес логике приложения процедуры обработки и сохранения полученных данных, всевозможные процедуры, реализующие специфические алгоритмы функционирования конкретного приложения. Часть подобных процедур вообще может запускаться не через вэб интерфейс. Также к бизнес логике я отношу глобальные алгоритмы функционирования ядра системы (если такое в проекте есть), процедуры авторизации пользователей, управления сессиями, ведения статистического учёта.
При этом все специфические действия, необходимые для отображению информации конкретным модулем, я считаю логикой отображения (выборка необходимых данных, форматирование, инициализация необходимых объектов, инициализация шаблона,,,).
Наиболее разумным, с моей точки зрения, является концентрация всех этих действий в одном определённом месте, я оформляю это в виде отдельной функции, если любитель оформлять это в виде отдельного класса. Это я называю модулем отображения информации, он отделён как от того, что я называю бизнес логикой, так и от HTML кода генерируемых им страниц. Ещё я отдельно выделяю модули управления информации, построенные немного по другой схеме, но и они не нарушают этих принципов.

Напомню, что я сторонник полного отделения программного кода от HTML кода, поэтому такие модули очень тесно связаны со структурой шаблона HTML кода страницы, но при грамотной разработке шаблонов он получаются достаточно гибкими, чтобы в 90% случаев необходимости изменения дизайна страницы не приходилось лезть в код модуля.

 

[Нечто]

ONK, спорить не буду - Ваше право. Мне такое разграничение функций кажется странным (нужно уточнить терминологию).
Я не отношу к логике представления инициализацию шаблонов, процесс выборки данных и пр. (использую такой же подход как 2NetFly)

 

[kvf77]

В конечном итоге, как правильно говорил Фанат, нельзя разъединить логику от представления. Шаблон, даже самый простой, всеравно знает где и как хранятся данные, пусть даже и подготовленные. Получается, что в погоне за идеей разделения, мы просто городим огород. Активный шаблоны прекрасно может парсить данные в цикле, и стоит ли разделять эту функцию на кучу файлов? Ведь от того, что мы распарсим массив в php файле, а не в шаблоне сильно ничего не изменится.
Глубокий уровень абстракции помоему нужен только для какой-нить дипломной работы, где этот уровень и изучается.

 

[Фанат]

ППКС
разумно и чётко изложено то, что я пытался сказать длинно и невнятно.

 

[BeGe]

Автор оригинала: kvf77
Ведь от того, что мы распарсим массив в php файле, а не в шаблоне сильно ничего не изменится.

Пример может не совсем удачный но всё же.

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

 

[Дмитрий Попов]

Ничего не изменится: Вывод - такой подход бесполезен, так как от него ничего не меняется.

 

[kvf77]

to: BeGe
Ну не совсем не изменится - у нас появится лишний файл-обработчик. К тому же, в твоем случае, если меняется структура данных - то мы будем править 2 файла, а не 1. Поправить шаблон проще - потому что в нем и парсится и выводится инфо.

 

[BeGe]

kvf77, уже противоречим самоу себе ?
Ты начал оперировать понятием массив, я тебе приедолжил ипользовать для данных - ресурс (ниже уровень или выше не имеет значения), то есть любая обработка данных в шаблоне это бред.

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

Пару тезисов.

1. Обработка данных и подготовка к анализу должна быть в "модели"
1.1 Если данны не подготовить к анализу, первый шаг не нужен.
2. Анализ данных и их отображение в шаблоне.
3. "модель" не должна использовать только стандартный набор типов данных (строка, число, массив), должны быть типа данных такие как (таблица, кнопка, дроп даун лист, хлебные крошки, меню ......). Всё зависит от уровня абстракции.
4. "вид" должен знать как отображать тот или иной тип данных

P.S.
И в принципе шаблоны движки, которые существую, должны отличтася только количеством отображаемых типов.

Я могу ошибася, но всё же....

 

[kvf77]

Я говорил вообще-то о другом. Есть ассоциированный массив из N элементов. Можно его парсить в скрипте вызывая N раз шаблон. А можно передать массив шаблон и он там в цикле будет распарсен.

 

[2NetFly]

Господа, вы о чем вообще спорите? Я уже выше говорил, но, видимо, никто меня не услышал. Читаем и внимательно смотрим на диаграммы:
Service To Worker - получением данных и их подготовкой занимается контроллер.
Dispatcher View - получением данных занимается представление, активный шаблон.

И нет здесь "единственно правильного" решения, которое некоторые пытаются изобрести и доказать, что оно таковым является.

 

[Дмитрий Попов]

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

Вот все говорят о разделении каких-то мифических логик представления, бизнес-логик и других видов логик.
При том никто не смог четко провести грань между ними.
Я же смотрю на вопрос проще:
Шаблоны мне нужны, банально, что бы отделить HTML от PHP. И всё.
Не логику от логики, а логику как таковую от представления.

Это понятно мне. Это более чем понятно дизайнеру.
Если мне надо исправить внешний вид элемента - я лезу в HTML и легко его правлю.

Если надо исправить поведение элемента (как раз к слову о количестве ячеек, или цветной раскраски) - я правлю PHP.

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

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

 

[neko]

раскраска не является поведением

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

 

[Дмитрий Попов]

neko
Цвет - не является.

Сколько видов цвета, и как они чередуются - является.

В чередовании цветов есть логика. Всегда. Это доказывается элементарно: Для того, что бы реализовать вывод строк разного цвета, необходимо использовать хотя бы одну логическую функцию. Или по другому: Вывод цветов подчиняется строго заданному алгоритму.

Так вот - алгоритмы я храню в PHP. Для реализации алгоритмов используется программирование. В HTML хранится только и исключительно оформление. Т.е. то, для чего html и создан.

При таком подходе, повторюсь: Всегда можно разделить: что нужно хранить в шаблонах, а что в коде. Независимо от того, насколько бурная фантазия у разработчика, и сполько видов логики он знает и/или придумает.

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

невижу противоречия с тем, что я написал постингом выше.

 

[neko]

Дмитрий Попов
не надо мне ничего элементарно доказывать ;-)

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

> При том никто не смог четко провести грань между ними.

конечно не смог.

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

-~{}~ 25.05.05 21:18:

да и вот это:

> Это понятно мне. Это более чем понятно дизайнеру.

правильно будет звучать:
"Это понято мне. Это понятно моему дизайнеру."

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

-~{}~ 25.05.05 21:22:

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

 

[Дмитрий Попов]

neko
Забавно Вы перефразируете. Очень забавно =).

Это понятно мне. Это более чем понятно дизайнеру.

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

А вот собственно забавное перевертывание моей фразы:

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

Покажите мне, где я это писал ))))
Я писал что нельзя универсально разделить логику представления и ну, допустим, бизнес логику. Разницу чуете? Не

А то взяли, и фразу, которую я пытался доказать два последних постинга вы вдруг выдвинули как фразу, против которой я выступаю. "Это конь черный! Нет - белый!" (с) - каспаров.

-~{}~ 25.05.05 23:27:

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

Вы каким местом моё сообщение читали, простите? Я в нём абсолютно тоже самое написал, если вы заметите.