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

[Alexandre]

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

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

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

Подход второй - происходит все-таки смешение логики отображения и представления.
что на твой взгляд правильнее??

что эффективние, с точки зрения командной работы?

 

[itprog]

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

-~{}~ 13.05.05 15:20:

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

 

[ONK]

IntenT, объясни мне что такое логика данных? Это их подготовка?, или их извлечение?, или что-то ещё?

Мое мнение - код должен достать данные, обработать, и передать куда-то, чтобы отобразить их (например шаблонизатору).
Как отобразить - полностью дело этого шаблонизатора.

Alexandre

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

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

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

 

[Alexandre]

Верстальщик получает прилично, практически столько же сколько и программист

факт, меньше и на много

грамотных XML/XSLT верстальщиков вообще днем с огнем не сыскать

написать руководство для верстальщика + комментировать все шаблоны

так и работаем....
пишем шаблоны, а он на них уже натягивает дизайн

 

[itprog]

факт, меньше и на много

Если сравнивать как обычные числа. У верстальщик все же работа намного легче(а задача программистов усложнить ее ).

 

[Alexandre]

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

а вот код инициализации шаблона может быть и в головном модуле. Вопрос, который уже возникал:
необходимо отобразить почти на каждой странице:
- новостную ленту
- 10 топ хитов вариант 1
- 10 топ хитов вариант 2
- текущую карзину
- банеры
где эти модули распологать
как в этом случае организовать шаблоны
как организовать сбор данных работы этих модулей

 

[IntenT]

Alexandre

Нужно ли строить такой шаблон, чтоб он полностью отвечал за все представление

имхо, только такие и нужно делать

ONK

объясни мне что такое логика данных? Это их подготовка?, или их извлечение?

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

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

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

 

[ONK]

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

И всёравно я не понял о чём речь?

Если у меня модуль отвечает за отображение некой информации, то в нём нет никакой логики не связанной с этой задачей.

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

Под понятие "изменение представления данных" можно подвести даже преобразования связанные бизнес логикой приложения. Так что это пустые слова.

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

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

Alexandre, Я не понял твоего вопроса. Головной модуль может генерировать свои независимые элементы страницы (такие как главная навигация сайта), при этом ему никто не мешает объединять вывод нескольких независимых модулей.

 

[Alexandre]

при этом ему никто не мешает объединять вывод нескольких независимых модулей
ONK

т.е. другими слоовами:
модуль генерит данные используя свой шаблон (файл)

головной модуль
собирает данные, генерируемые вызываемыми модулями (классами)
и объединяет в общую страницу ( ген шаблон - отдельный файл )

я правильно понял?

тоесть хотим в столбик - имеем в столбик, хотим в 5 колонок по диагонали снизу вверх - имеем в 5 колонок по диагонали снизу вверх исключительно средствами шаблонизатора.
IntenT

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

улучшиться ли от этого эффективность командной работы?

-~{}~ 13.05.05 18:24:

на сколько такой шаблон будет понятен верстальщику

		<xsl:for-each select="raw">
		<tr class="c3" bgcolor="#ffffff">
			<xsl:if test=" ./../@id =1"> 
				<td >
				<xsl:element name="img">
					<xsl:attribute name="src">pic.php?id=<xsl:value-of select="@id"/></xsl:attribute>
					<xsl:attribute name="width">60</xsl:attribute>
				</xsl:element>
				</td>
			</xsl:if>

			<td ><a class="menu2" >
					<xsl:attribute name="href">licensor.php?pagenum=edit&amp;id=<xsl:value-of select="@r_id"/>&amp;contract_id=<xsl:value-of select="@contract_id"/>&amp;type=<xsl:value-of select=" ./../@id"/></xsl:attribute>
				<xsl:value-of select="@code"/></a>		
			
			</td>
			
			<td ><xsl:value-of select="@pcode"/></td>
			<td ><xsl:value-of select="@name"/></td>
			<xsl:if test=" ./../@id =2"> 
				<td ><xsl:value-of select="@perfomer"/></td>				
			</xsl:if>

			<td ><xsl:call-template  name="code">
				   <xsl:with-param name="code" select="@code"/>
				</xsl:call-template></td>
			<td ><xsl:apply-templates select="." /></td>
			<td ><xsl:value-of select="@summa"/></td>
		</tr>
		
		</xsl:for-each>

 

[ONK]

я правильно понял?

В принципе правильно.

 

[Alexandre]

В принципе правильно

я тоже придерживаюсь такой концепции,
а что не так?

 

[ONK]

Alexandre, Данная архитектура приложения никак не зависит от используемых принципов шаблонизирования, я не понимаю к чему ты задаёшь вопросы в этом направлении.

 

[Alexandre]

Данная архитектура приложения никак не зависит от используемых принципов шаблонизирования

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

 

[Фанат]

ребят, а можно вас попросить сделать лицо попроще?

 

[slach]

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

 

[Фанат]

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

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

воспринимаю струдом, особенно по субботам =)

 

[bgm]

Архитектура архитектуры требует особых архитектурных построений, особенно при шаблонном архитектурировании...

it's flaim.

 

[Raziel[SD]]

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

 

[2NetFly]

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

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

 

[Нечто]

У ДК второй вариант реализации MVC, упомянутый 2NetFly, называется компонентым подходом и используется в его шаблонизаторе. Я против того, чтобы шаблонизатор превращался в CMF (как у ДК), но +1 за активные шаблоны.