{Smarty} плагин для работы с итератором

csa

Guest
а фильтр вызывается при получении строки - вызове метода fetchRow и обрабатывает только одну эту строку
 

Demiurg

Guest
> вызове метода fetchRow и обрабатывает только одну эту строку
а этим у тебя кто занимается ? правильно, шаблонный движок. вот и получаем бизнес-логику в шаблоне.
 

csa

Guest
вызов ее происходит при рендеринте, это да. но от самого шаблона она никак не зависит!

-~{}~ 05.03.04 17:39:

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

Demiurg

Guest
ну так модификторы в smarty тоже писать можно. В чем проблема то встала ?
 

csa

Guest
при чем тут модификаторы? у меня фильтр работает с ассоциативным массивом, в котором лежит одна строка из выборки

-~{}~ 05.03.04 17:59:

в общем-то, правильней было бы назвать его дописывателем, чтобы точнее отразить смысл его работы
 

lucas

Guest
в общем-то, правильней было бы назвать его дописывателем, чтобы точнее отразить смысл его работы
Дописывает он что? Правильно -- информацию, данные.
Вызывается он где? Снова правильно -- при обработке шаблона.

It seems to be, что схема генерации документа такая:
1. Получили часть информации.
2. Начали формировать шаблон.
3. Внезапно вспомнили, что часть данных мы зыбыли.
4. "Дописали" их, даже не сморщив нос от того, что это произошло в шаблоне.

И кто после этого не смешивает бизнес-логику и логику отображения? :)

К тому же, ИМХО, потребность достать какие-то данные уже на этапе парсинга/заполнения шаблона говорит прежде всего о непродуманной/безграмотной архитектуре приложения.
 

csa

Guest
тебя не смущает то, что плагины в смарти работают по тому же принципу?
дописываемые данные нигде, кроме как в шаблоне, не нужны, они не влияют на процесс построения страницы.

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

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

если проводить аналогию с COW, получаем RWN (Read When Need) ;-)
 

Demiurg

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

csa

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

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

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

lucas

Guest
тебя не смущает то, что плагины в смарти работают по тому же принципу?
Плагины в Smarty (ИМХО) предназначены для того, чтобы работать с уже полученными данными (переменными шаблона). Типичный пример -- разные стили квотинга -- для переменной JavaScript, для вставки в URL, для вставки в HTML...

Говорить что-то, наблюдая, как слова разбиваются о стену нежелания понять их ("У нас и так все ok..."), -- не самое лучшее времяпровождение, поэтому я присоединяюсь к Demiurg'у. Спасибо.
 

doppelganger

Guest
А вот, например, поле, по которому сортируется список -- это ещё бизнес-логика или уже представление?
 

Demiurg

Guest
doppelganger
скорее бизнес-логика. некоторые деньги платят за то, что бы стоять в начале списка.
 

doppelganger

Guest
Обезоружили. Но я в том смысле, что каждый раз менять order в скрипте -- неудобно. А smarty не умеет в секциях менять порядок, только limit. Грустно.
 

Demiurg

Guest
doppelganger
что значит не удобно ?
если записи разбиты по страницам, то номер выводимой страницы тоже логика дизайна ?
 

doppelganger

Guest
Нет, только его, номера, оформление. А вот количество записей на странице -- пожалуй, что и дизайн.
Что касается сортировки. Вот у меня есть список т.н. недельных комментариев, они могут сортироваться по автору, по названию главы и по названию книги. Клиент дважды менял своё решение по дизайну страницы -- то ему хотелось по авторам, то по книгам, в результате вывели по книгам и по главам (order by book, chapter). Будь на моём месте подневольный кодер, ему что -- в скрипт лезть и менять sql запрос? Грустно же.
 

Demiurg

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

csa

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

>3. Внезапно вспомнили, что часть данных мы зыбыли.
их "забыли" сознательно, дабы уменьшить оверхед/еще_сотня-другая_причин

>Плагины в Smarty (ИМХО) предназначены для того, чтобы работать с уже полученными данными ...
посмотри пример к include_php, а именно код для файла load_nav.php. приятно удивись
под плагинами я подразумевал (прошу прощения за допущенную неоднозначность) поставщиков некоторых опциональных данных (например, список последних сообщений из форума). выполнение или невыполнение 1-30 запросов к базе/бог_знает_к_чему_еще будет зависить исключительно от логики представления (кошмар, правда?)
так вот, в случае с итератор+фильтр-дописыватель+плагин_для_итератора все далеко не так страшно :)
но я увлекся, прошу прощения, можете не отвечать
 

doppelganger

Guest
Скрипт чуть хуже, потому что он, по идее, не должен меняться. Одно ядро у нас обслуживает шесть сайтов разом, невозможно логику одного менять ради прихоти. Пришлось выносить вещи типа сортировки в свой язык шаблонов. Но задачи этот кустарный шаблонизатор уже переросли, поэтому решил переходить на smarty. И тут такой удар со стороны классика -- нет у секций атрибутов. Можно, конечно, использовать блоки, но тогда теряются все прелести типа rownum. Вот мне и кажется, что в мечтаниях csa есть здравое зерно.
 

Demiurg

Guest
doppelganger
ты хочешь сказать, что на все шесть сайтов одни и теже скрипты ( то, есть физически используются одни и те же файлы) а различаются только шаблоны ? Помоему это не правильно.
 

doppelganger

Guest
Да, именно так. Разные базы и шаблоны. Всё исключительно от лени, потому что так поддерживать проще.
 
Сверху