логика представления и логика выполнения. Что куда???

Kelkos

Сам себе программер
ради мнимой идеи отделения ТРИВИАЛЬНОЙ логики от шаблона люди пишут интерпритаторы шаблонов. ух.
Сколько не читаю трёп о шаблонах сложилось мнение, что шаблоны нужны прежде всего для того, чтобы не дать дизайнеру/верстальщику возможность писать потенциально опасный код в шаблонах.
Моя всегда думал, что писать интерпретатор языка на некомпилируемом языке - маразм..
Для того, чтобы верстак с дизайнером не могли зафигачить код в шаблон с кодом есть другие методы. Например цифровая подпись пхп кода в шаблоне.
 

Денч

Новичок
PHP:
<? if(...): ?> 
   <font color='red'><?=$user_name?></font> 
<? else
echo $user_name;
<? endif; ?>
Так понятнее. Я, конечно, довольно слаб в таких вещах, но уже понимаю, что без логики в шаблоне никуда не деться.

ЗЫ Это вариант 1 по Alexandre

Моя всегда думал, что писать интерпретатор языка на некомпилируемом языке - маразм..
Моя тоже так думает:)
 

BeGe

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

Alexandre

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

Ну, Например, в ряде случаев, можно сортировку вывести на уровевь шаблона. Много народа так делвет ?? - очевидно нет.

изменение подсветки... речь идет не о вставке конкретного цвета, а есть цвета:
- активный color
- пассивный color

они могут задаваться, как указыывалось в инифайлах
Но Представление может быть как таким:
PHP:
<a href="..." class="{tpl_if name='color' op='==' value='1' }    {tpl_var name='PassivColor'}
{tpl_else}
    {tpl_var name='ActivColor}
{/tpl_if}">ссылка </a>
так и таким
PHP:
<a href="..." class="{tpl_var name='color'  } ">ссылка </a>
значение вычисляется в программе.

Кстати от возможности шаблонизатора мало что зависит, если правдо это не шаблонизаторы без реализации логики :)
 

WMix

герр M:)ller
Партнер клуба
Конечно мой топ возможно будет неуместен, по причине что вы все говорите о смарте иль ещё чтот подобное, но вначале этой дискусии я читал про реализации при помощи XSLT.

те. я нехочу затрагивать проблемы многоязыковых интерфейсов, потому как это тоже решается на уровне логики
Модель возвращяет голый xml где слово "ТЫРК" для кнопки уже написанно, осталось только кнопку нарисовать!

<button name="save" value="ТЫРК"></button>

<xsl:template match="button">
<input type="submit" >
<xsl:copy-of select="@*"/>
</input>
</xsl:template>

это представление: хмл - делайте как угодно... хоть смарти...
но всеже вспомните про ту золотую середину о которой упоменал BeGe .....

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


IHMO Задачи View несколько другие...
те. я реализовал вывод хмл документа не только в html но и с помощью fpdf в pdf... а креативные ребята может напишут представление в виде gif или там svg ...

конечно Дезигнер а лучше скажем верстальшик должен знать
XSLT... Это проблемма??

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

Alexandre

PHPПенсионер
потому как это тоже решается на уровне логики
какой логики: представления или отображения?
Например, что мешает сделать так ( логика в шаблоне) :
PHP:
<xslt:template match="...">
   <xsl:variable name="lang" select="..." /> // во входном XML где-то определяем язык отображения
...
    <input type="button">
         <xsl:attribute name="value">
                <xsl:if test="$lang='ru'"><xsl:value-of select="/root/inputButtonsName[@lang='ru']"><xsl:test>
                <xsl:if test="$lang='en'"><xsl:value-of select="/root/inputButtonsName[@lang='en']"><xsl:test>
         </xsl:attribute>
    </input>
</xslt:template>
// инклудим lang.xml
<root>
   <inputButtonsName lang="ru">ГЫК</inputButtonsName>
   <inputButtonsName lang="en">GJOOOK</inputButtonsName>
или логика в представлении, тогда шаблон упростится до
Код:
    <input type="button">
         <xsl:attribute name="value">
            <xsl:value-of select=".../ButtonName "
         </xsl:attribute>
    </input >

ЗЫ, а как я уже упоминал смарти то или ХСЛТи - значение не имеет, суть в идеалогии.
 

IntenT

SkyDiver
Alexandre

В чем принципиальная разница между первым и вторым вариантом?
 

Alexandre

PHPПенсионер
В чем принципиальная разница между первым и вторым вариантом
в первом варианте - данные определенны значением $lang, которые выбирает сам шаблон, или логика отображения конструкция:<xsl:if>

во втором варианте - данные подставляются контроллером шаблона или логикой представления, т.е. они уже определены в <xsl:value-of select=".../ButtonName "/>


терминология не устоявшиеся...
 

IntenT

SkyDiver
Alexandre
Эта конструкция
PHP:
<xsl:if test="$lang='ru'"><xsl:value-of select="/root/inputButtonsName[@lang='ru']"><xsl:test>
на мой взгляд бессмысленная, потому что заменяется на
PHP:
<xsl:value-of select="/root/inputButtonsName[@lang=$lang]">
При этом никакой разницы, откуда брать значение ноды я не вижу

Вся разница в твоем примере сводится к
PHP:
<xsl:value-of select=".../ButtonName "/>
или
PHP:
<xsl:value-of select="/root/inputButtonsName[@lang=$lang]">
где и .../ButtonName и /root/inputButtonsName[@lang=$lang]- абсолютно одинаковые с точки зрения логики выражения XPath
 

Денч

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

Читая ваши обсуждения, я учусь, но просто путаюсь в терминах, что есть что
 

WMix

герр M:)ller
Партнер клуба
логика представления это то что преобразит созданное генератором данных в законченый вид... наверно так
 

Sherman

Mephi
XSLT — это неплохо, но есть два минуса:

1. Генерация данных: бд->xml->ouput, т.е. появляется лишнее звено xml, хотя в нормально написанных системах, это не проблема.

2. Квалификация верстальщика. Их, не так много, как кажется, тех, кто работает с XSLT, хотя бы.

Вот вам пример из жизни. Мне все макеты приходят вообще ввиде фотожопных файлов, при просьбе заверстать, на почту пришло непотребство, сгенерированное dreamweaver 2004 mx. А если нужно сделать какой-то функционал на DHTML, то это вообще проблема для верстальщиков.

Опять же пример из жизни. Нужно сделать поле text-area, с возможностью увеличивать/уменьшать свои размеры и запоминать это дело для каждого пользователя.

Т.е. есть куча полей, в разных формах, но у них уникальные идентифкаторы. Казалось бы не сложная задача, все что нужно знать, это основы DOM и работу с cookies, но даже это повергло в ступор.

В конечном итоге вопрос сводится к деньгам. Способна ли фирма нанять квалифицированного верстальщика, для того, чтобы разгрузить программиста или нет.

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

Alexandre

PHPПенсионер
IntenT
согл - пример не удачно подобрал,
но принципиальную суть, я надеюсь , ты уяснил ?

Генерация данных: бд->xml->ouput, т.е. появляется лишнее звено xml
Sherman - звено то как раз и не лишнее, а представляет промежуточный слой представления данных в идеаологии МВиСи.

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

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

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

Для проектов, которые просто отображают плоскую таблицу без всякого там анализа - возможно применение МВиСи излишнее.
 

WMix

герр M:)ller
Партнер клуба
ну чтож дело вкуса!.. я сам был в восторге от FastTemplate потом познакомился с смарти вообше офигенно.. но более удобного инструмента чем хслт пока ненашел!!..

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

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

Все это да и многое другое тебя самого не заставляет задуматься о действительно лишних звеньях в программе?

-~{}~ 10.08.05 18:35:

единственное с чем соглашусь может так это цена....
но цена вся упирается В ПЕРЕРАБОТКУ ТВОИХ НАРАБОТОК!!!
 

WMix

герр M:)ller
Партнер клуба
Опять же пример из жизни. Нужно сделать поле text-area, с возможностью увеличивать/уменьшать свои размеры и запоминать это дело для каждого пользователя.

Т.е. есть куча полей, в разных формах, но у них уникальные идентифкаторы. Казалось бы не сложная задача, все что нужно знать, это основы DOM и работу с cookies, но даже это повергло в ступор.
Кстати про арея так и непонял в чем проблема!!
это одному пользователю можно менять несколько полей по размерам??

если одному одно... то ни кукисы ни индификаторы ненужны!!
одной сесии достаточно

если много полей просто имена им дать подобающие,

ид это просто метка в коде для удобного нахождения!!!

а как ты туда дом прикрутил (если ты о пхп) вообще непойму
 

Domovoj

Guest
Автор оригинала: Alexandre
изменение подсветки... речь идет не о вставке конкретного цвета, а есть цвета:
- активный color
- пассивный color

они могут задаваться, как указыывалось в инифайлах
Но Представление может быть как таким:
PHP:
<a href="..." class="{tpl_if name='color' op='==' value='1' }    {tpl_var name='PassivColor'}
{tpl_else}
    {tpl_var name='ActivColor}
{/tpl_if}">ссылка </a>
так и таким
PHP:
<a href="..." class="{tpl_var name='color'  } ">ссылка </a>
значение вычисляется в программе.

Кстати от возможности шаблонизатора мало что зависит, если правдо это не шаблонизаторы без реализации логики :)
Я за первый вариант. На мой взгляд всё, что относится к выбору цвета, положения, отображения и сокрытия каких-либо участков надо в tpl класть. А вот вычисление условий, при которых этот выбор должен осуществляться и т.д., должно быть в php. Тогда, в шаблонах остануться примитивные if ($condition) {} и foreach() {}. (причём $condition может быть составным через OR, AND и т.д, но не содержит никаких вычислений и выборок). Соответственно в самом первом примере (замена "Добавить/Удалить" на "Add/Delete") определние, что это, Add или Delete должно быть в PHP, а вот вывод самого названия в tpl, что-то типа:
PHP:
<input type='submit' value='{if $isDeleteButton}{$lng_delete}{else}{$lng_add}{/if}'>
 

BuTbKa

Новичок
почему бы не передавать название кнопки переменной в шаблон?
 
Сверху