-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
htmlspecialchars - дело верстальщика или программиста?
- Автор темы Фанат
- Дата начала
Demiurg
Guest
>А эта мысль совсем не понятна, можно пояснить подробнее?
имеем get запрос script.php?var1=...&var2=...
в скрипте получаем четыре переменные:
$_GET['var1_ecaped']
$_GET['var1_raw']
$_GET['var2_ecaped']
$_GET['var2_raw']
На сколько я понимаю, это аналог идеи передачеи данных в разном формате шаблону, только в другом применении.
имеем get запрос script.php?var1=...&var2=...
в скрипте получаем четыре переменные:
$_GET['var1_ecaped']
$_GET['var1_raw']
$_GET['var2_ecaped']
$_GET['var2_raw']
На сколько я понимаю, это аналог идеи передачеи данных в разном формате шаблону, только в другом применении.
Demiurg
Guest
Причем тут передача данных ? Данные передается как и раньше, только php теперь делает 2 переменные.
ONK
Пассивист PHPСluba
Передача данных от клиента к серверу это совершенна отдельное действие, имеющее свои собственные особенности обработки совершенно никак не связанные с обработкой шаблонов.
Несколько примеров:
1. Содержимое переменных полученных от клиента не предсказуемо, в то время как содержимое переменных получаемых блоком шаблона гарантировано.
2. При передаче данных от клиента к серверу следует передавать минимально необходимый объём данных, в то время как при обработке шаблона нет никакого смысла в ограничении количества обрабатываемых переменных.
3. При приёме данных от клиента скрипт в первую очередь должен уметь правильно обработать их, а при передачи значений переменных в шаблон главное мксимально уменьшить вероятность возникновения ошибок по вине того, кто будет этот шаблон редактировать.
Поэтому не стоит переводить обсуждение тему в область передачи данных между клиентом и сервером.
И ещё, я видел верстальщика, который полностью сам писал шаблоны имея только перечень блоков, располеженных в последовательности их использония скриптом реализующим логику представления, и доступных в этих блоках переменных с кратким описанием их назначения. Но в случае со смарти это конечно просто не возможно.
Несколько примеров:
1. Содержимое переменных полученных от клиента не предсказуемо, в то время как содержимое переменных получаемых блоком шаблона гарантировано.
2. При передаче данных от клиента к серверу следует передавать минимально необходимый объём данных, в то время как при обработке шаблона нет никакого смысла в ограничении количества обрабатываемых переменных.
3. При приёме данных от клиента скрипт в первую очередь должен уметь правильно обработать их, а при передачи значений переменных в шаблон главное мксимально уменьшить вероятность возникновения ошибок по вине того, кто будет этот шаблон редактировать.
Поэтому не стоит переводить обсуждение тему в область передачи данных между клиентом и сервером.
И ещё, я видел верстальщика, который полностью сам писал шаблоны имея только перечень блоков, располеженных в последовательности их использония скриптом реализующим логику представления, и доступных в этих блоках переменных с кратким описанием их назначения. Но в случае со смарти это конечно просто не возможно.
Demiurg
Guest
Вот в этом то и дело, что ты пытаешься все смешать в кучу. Мне, лично, нравится принцип разделяй и влавствуй. Кто сказал, что шаблон получает только валидные данные ? Он получает только данные для отображения. И их отображает. Все.
Таким образом можно сразу понять, где ошибка в скриптах или в шаблоне.
Таким образом можно сразу понять, где ошибка в скриптах или в шаблоне.
svetasmirnova
маленький монстрик
Только что включила компьютер, поэтому запоздало отвечаю всем сразу 
ONK
>1 Чем отличаются правила формирования гиперссылок (точнее обработка значений передаваемых параметров), от тех-же в HTML?
В HTML могут быть атрибуты, невалидные в WML.
>2 Чем отличается обработка передаваемых значений содержащих произвольные данные, от тех-же в HTML?
Например, кодировка. В HTML это может быть, например, CP1251, а в WML она должна быть UTF8 или UTF16. И только не советуйте мне делать сайты на UTFХ
Фанат
>Это хороший довод.
Как всегда забыла про свой любимый подход: сначала взгляни на время жизни проекта. (Впервые прочитала у Леона Аткинсона в книге "MySQL ...") То есть для некоторых проектов заранее может быть известно где будут данные и вы правы. С другой стороны я, наверное неудачно, пыталась проиллюстрировать такой момент: есть переменная, всегда содержащая данные, предназначенные для определённой цели, которую можно выводить в разных форматах, в которых разбирается "верстальщик", но фичи которых может легко забыть программист.
, который не может держать в голове правила вывода в разных форматах и одновременно решать сложные (или занудливые) программистсткие задачи.
Demiurg
Я тут сегодня подумала, что в случае небольших краткосрочных проектов наши (мои ?) оппоненты могут быть правы, особенно если не использовать шаблонные движки типа Smarty: программист может batch методом обработать все переменные и передать их в шаблон. Без надстроек-шаблонизаторов над raw PHP это не просто сделать.
ONK
>1 Чем отличаются правила формирования гиперссылок (точнее обработка значений передаваемых параметров), от тех-же в HTML?
В HTML могут быть атрибуты, невалидные в WML.
>2 Чем отличается обработка передаваемых значений содержащих произвольные данные, от тех-же в HTML?
Например, кодировка. В HTML это может быть, например, CP1251, а в WML она должна быть UTF8 или UTF16. И только не советуйте мне делать сайты на UTFХ
Фанат
>Это хороший довод.
Как всегда забыла про свой любимый подход: сначала взгляни на время жизни проекта. (Впервые прочитала у Леона Аткинсона в книге "MySQL ...") То есть для некоторых проектов заранее может быть известно где будут данные и вы правы. С другой стороны я, наверное неудачно, пыталась проиллюстрировать такой момент: есть переменная, всегда содержащая данные, предназначенные для определённой цели, которую можно выводить в разных форматах, в которых разбирается "верстальщик", но фичи которых может легко забыть программист.
Даже если это один и тот же человек
, который не может держать в голове правила вывода в разных форматах и одновременно решать сложные (или занудливые) программистсткие задачи.Demiurg
Я тут сегодня подумала, что в случае небольших краткосрочных проектов наши (мои ?) оппоненты могут быть правы, особенно если не использовать шаблонные движки типа Smarty: программист может batch методом обработать все переменные и передать их в шаблон. Без надстроек-шаблонизаторов над raw PHP это не просто сделать.
ONK
Пассивист PHPСluba
svetasmirnova
2. Атрибуты здесь вообще не причём. Если есть шаблон для генерирования WML, то его надо составить так, чтобы он соответствовал стандарту WML. А про обработку сложных типов данных я написал в первом своём сообщении (именно к такой обработке следует отнести преобразование данных с целью удаления невалидных атрибутов).
На самом деле на сколько я вижу наш спор плавно упирается в различия используемых принципов шаблонизирования. Те кто использует смарти считают совершенно логичным указание обработчиков данных прямо в шаблоне. Те кто предпочитает использовать шаблонизирование без каких либо включений логических операций считают более правильным использование переменных заданного типа.
По поводу объёмности/краткосрочности проекта, этот параметр никак не зависит от используемого способа шаблонизирования.
Более того, я могу представить не сложную схему, используя которую можно добить большей гибкости, надёжности и полного разделение работы программиста от работы дизайнера, при использование шаблонов без логики.
Этот довод нельзя признать состоятельным по двум причинам. 1. Вопрос был не об этом
2. Атрибуты здесь вообще не причём. Если есть шаблон для генерирования WML, то его надо составить так, чтобы он соответствовал стандарту WML. А про обработку сложных типов данных я написал в первом своём сообщении (именно к такой обработке следует отнести преобразование данных с целью удаления невалидных атрибутов).
Это уже ближе к теме, хотя опять же я спрашивал про обработку специальных символов, которая как и в 1 вопросе совпадает с такой же обработкой в HTML. Что касается кодировки, то для документов рассчитанных на экспортирование в несколько форматов вполне логично выбрать ту кодировку, которая будет работать везде (UTF8 , UTF16).
На самом деле на сколько я вижу наш спор плавно упирается в различия используемых принципов шаблонизирования. Те кто использует смарти считают совершенно логичным указание обработчиков данных прямо в шаблоне. Те кто предпочитает использовать шаблонизирование без каких либо включений логических операций считают более правильным использование переменных заданного типа.
По поводу объёмности/краткосрочности проекта, этот параметр никак не зависит от используемого способа шаблонизирования.
Более того, я могу представить не сложную схему, используя которую можно добить большей гибкости, надёжности и полного разделение работы программиста от работы дизайнера, при использование шаблонов без логики.
Demiurg
Guest
>Более того, я могу представить не сложную схему, используя
>которую можно добить большей гибкости, надёжности и
>полного разделение работы программиста от работы
>дизайнера, при использование шаблонов без логики.
Было бы интересно. И еще при этом рассмотреть возможность кординальной смены дизайна.
>которую можно добить большей гибкости, надёжности и
>полного разделение работы программиста от работы
>дизайнера, при использование шаблонов без логики.
Было бы интересно. И еще при этом рассмотреть возможность кординальной смены дизайна.
svetasmirnova
маленький монстрик
ONK
>Те кто использует смарти
Я не использую, просто я его лучше знаю, чем другие шаблонные движки. Я использую selfmade гибрид (см. http://phpclub.ru/talk/showthread.php?threadid=60579&goto=newpost)
>вполне логично выбрать ту кодировку, которая будет работать везде
Вот только везде ли?
И ответьте Demiurg, пожалуйста
>Те кто использует смарти
Я не использую, просто я его лучше знаю, чем другие шаблонные движки. Я использую selfmade гибрид (см. http://phpclub.ru/talk/showthread.php?threadid=60579&goto=newpost)
>вполне логично выбрать ту кодировку, которая будет работать везде
Вот только везде ли?
И ответьте Demiurg, пожалуйста
ONK
Пассивист PHPСluba
Demiurg, Схема очень проста но требует дополнительной работы, поэтому её разумнее всего применять для особенно важных частей проекта.
Принцип такой, создаётся дополнительный программый уровень (слой) отвечающий именно за логику отображения информации. Это скрипт (я его оформляю в виде отдельной процедуры/функции), который вызывается движком проекта для создания и отображения конкретной страницы.
Этот скрипт реализует весь перечень необходимых действий по извлеченью данных, предварительной их обработки и инициализации этими данными блоков шаблона.
Таким образом получается взимосвязанная система из скрипта отвечающего за логику отображения информации и шаблона в котором находится исключительно дизайн генерируемого документа, разделённый на элементарные блоки.
Эта схема полностью разделяет работу дизайнера и программиста, тем самым исключая возможность возникновения большого количества ошибок связанных выполнением не профильной работы. Разумеется такая схема позволяет сделать кординальное изменение всего дизайна и функциональности связанной с генерируемым документом. Просто для этого необходима параллельная корректировка скрипта обеспечивающего реализацию логики представления и шаблона содержащего дизайн. При этом по понятным причинам можно добиться большей гибкости (собственно она ограничена только набором данных). Даже если корректировку шаблонов и скрипта выполняет один человек, то раздельное корректирование более удобно из-за строгого разделения программной части и дизайна.
Это особенно заметно при работе со сложными шаблонами которые обслуживаются достаточно объёмными скриптами обработки логоки отображения (аналогичная конструкция на шаблонах смарти будет выглядить просто пугающе).
svetasmirnova, Там где не поможет UTF боюсь не поможет ничто (или выражусь подругому, возможность наложения фильтров в шаблоне этому тоже не поможет)
Принцип такой, создаётся дополнительный программый уровень (слой) отвечающий именно за логику отображения информации. Это скрипт (я его оформляю в виде отдельной процедуры/функции), который вызывается движком проекта для создания и отображения конкретной страницы.
Этот скрипт реализует весь перечень необходимых действий по извлеченью данных, предварительной их обработки и инициализации этими данными блоков шаблона.
Таким образом получается взимосвязанная система из скрипта отвечающего за логику отображения информации и шаблона в котором находится исключительно дизайн генерируемого документа, разделённый на элементарные блоки.
Эта схема полностью разделяет работу дизайнера и программиста, тем самым исключая возможность возникновения большого количества ошибок связанных выполнением не профильной работы. Разумеется такая схема позволяет сделать кординальное изменение всего дизайна и функциональности связанной с генерируемым документом. Просто для этого необходима параллельная корректировка скрипта обеспечивающего реализацию логики представления и шаблона содержащего дизайн. При этом по понятным причинам можно добиться большей гибкости (собственно она ограничена только набором данных). Даже если корректировку шаблонов и скрипта выполняет один человек, то раздельное корректирование более удобно из-за строгого разделения программной части и дизайна.
Это особенно заметно при работе со сложными шаблонами которые обслуживаются достаточно объёмными скриптами обработки логоки отображения (аналогичная конструкция на шаблонах смарти будет выглядить просто пугающе).
svetasmirnova, Там где не поможет UTF боюсь не поможет ничто
(или выражусь подругому, возможность наложения фильтров в шаблоне этому тоже не поможет)
svetasmirnova
маленький монстрик
А разделение логики и отображения тогда где, раз весь перечень?
svetasmirnova
маленький монстрик
Смотрите, что вы написали:
----------
Этот скрипт реализует весь перечень необходимых действий по извлеченью данных, предварительной их обработки и инициализации этими данными блоков шаблона.
----------
То есть получается схема (грубо):
script->template
извлеченье данных, предварительная их обработка и инициализация этими данными блоков шаблона->отображение
Но во время обработки для отображения "скрипт" не абстрагируется от отображения, а, наоборот, обеспечивает соответствие отображаемых данных выводу: см. полемику выше.
Логичнее было бы сделать a-la MVC:
script->data_handler->template
извлеченье данных->предварительная их обработка и инициализация этими данными блоков шаблона->отображение
ONK
Пассивист PHPСluba
svetasmirnova, я кажется ясно написал, что выделяется дополнительный программный слой обеспечивающий реализацию логики отображения.
-~{}~ 07.01.05 15:22:
Фанат,
Оба подхода имеют равные права на жизнь.
-~{}~ 07.01.05 15:22:
Фанат,
Это само собой разумеется. Просто можно и логику отображения и дизайн свалить в одну кучу внутри одного шаблона и сказать, что это очень гибко. А можно отделить логику отображения от дизайна и от логики приложения, в результате окажется что это ещё более гибкое решение.
Оба подхода имеют равные права на жизнь.
Demiurg
Guest
дизайн и логика отображения - это одно и тоже.
и как раз его от логики приложения, от бизнес-логики, от контроллера - от (вставьте сюда свой собственный умный термин) - НЕ ОТДЕЛЯЕТСЯ.
Стопроцентно разделить верстальщика и программиста, чтобы изменения в дизайне могли производиться ТОЛЬКО действиями верстальщика - НЕВОЗМОЖНО!
-~{}~ 07.01.05 16:32:
сколько строк будет в таблице при постраничном выводе - это бизнес-логика?
Стопроцентно разделить верстальщика и программиста, чтобы изменения в дизайне могли производиться ТОЛЬКО действиями верстальщика - НЕВОЗМОЖНО!
-~{}~ 07.01.05 16:32:
сколько строк будет в таблице при постраничном выводе - это бизнес-логика?
Demiurg
Guest
>Стопроцентно разделить верстальщика и программиста,
>чтобы изменения в дизайне могли производиться ТОЛЬКО
>действиями верстальщика - НЕВОЗМОЖНО!
Бесспорно, поэтому я и говорил, что прогрммист всегда прикладывает руку к шаблонам. А вот разделить сами логики можно.
>сколько строк будет в таблице при постраничном выводе - это бизнес-логика?
да
>чтобы изменения в дизайне могли производиться ТОЛЬКО
>действиями верстальщика - НЕВОЗМОЖНО!
Бесспорно, поэтому я и говорил, что прогрммист всегда прикладывает руку к шаблонам. А вот разделить сами логики можно.
>сколько строк будет в таблице при постраничном выводе - это бизнес-логика?
да