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

Фанат
А, это да... Я, кстати, так и не понял, что за кусок кода привели от смарти. Но что-то страшное.
И, кстати, согласен с одним очень сильно:
За что я обожаю Xtpl - так это за то, что его шаблоны являются - html-шаблонами. За редким исключением ввиде возможности конструкции {FILE}
 

Фанат

oncle terrible
Команда форума
Кусок кода от смарти - это кусок из конструктора Лего.
то есть, там пошли по пути конструирования инпутов на все случаи жизни.
html_select_date - конструктор ввода даты селектами
field_separator - понятно
field_order - понятно
all_extra - тоже понятно. Самый забавный, кстати, параметр. Пиши, что хочешь. id, класс, яваскрипт.
Вот такой наборчик "сделай сам".
 
Забавно. Я даже, кажется, начал понимать, зачем так забавно сделано.

Но форм-генератион, это отдельная тема. Хотя тоже интересная.
 

Фанат

oncle terrible
Команда форума
Вот именно. Легко понять, почему там так сделано.
потому, что в таком инпуте кода будет больше, чем html =)
Собственно, именно этим и вызван мой вопрос. Как решать такую проблему - "вывод черезвычайно насыщенного кодом куска отображения, без потери возможности редактировать это отображение".
 
Ага. Ну, как я понимаю, с XTPL все понятно?

Это будет обычный html с инпутами, только у каждого optiona будет дополнительно написано нечто вроде:
{month_option1.selected}
{month_option2.selected}
etc.
Это если все ручками рисовать.

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

Demiurg

Guest
Дмитрий Попов
в смарти тоже самое, если человек думать будет.
 

Sam

Новичок
Фанат
, ты говоришь что Alexandre и иже с ним "витают" в своих абстракциях, а сам ушёл в другую абстракцию не меньше их. печёшься о верстальщике, не дай бог ему подумать придётся.. по твоему верстальщик - что-то вроде регулярного выражения с ручками и ножками, который способен только заменить один хтмл блок другим?

Увидел в шаблоне html_select_date - пошёл на smarty.php.net - посмотрел что это. всё. это может любой верстальщик.

Стандарт - это хорошо, но иногда он слишком дорого стоит. (с) Demiurg
 

ONK

Пассивист PHPСluba
Sam, знаешь, лезть в мануал это достаточно трудная процедура, требующая напряжения множества моральных усилий и к тому же достаточно вредная с некоторой точки зрения, так как она отвлекает от текущего контекста и обычно растягивается на длительное время, тем самым существенно снижая общую производительность труда. ;)
Я предпочитаю посещать всевозможные мануалы только в крайних случаях.
 

Sam

Новичок
ONK
а прописывать в приложении каждый чих когда этот чих по сути - презентационная логика? не трудная процедура? )
 

Demiurg

Guest
Sam
лично я категорически против html_select_date
 

WeirD

Новичок
Господа...
Тегов подобных html_select_date, в смарти в общем-то больше и нет... Если не считать html_select_time, конечно ;)
Так что не все так плохо...
 

texrdcom

Новичок
возможно все не много усложнили

1) По чему люди бегут от Smarty: причина простая это приложение 150kb, чтобы его использовать нормально надо потратить определеное время - не день и не два, получаеться что кто то на php написал еще один програмнный язык - но разве мы с вами этим не занимаемся мы ведь тоже когда пишем скрипт создаем свои функции, классы, - это ведь тоже получаеться некий язык програмирования но написанный нами на php, у каждого есть своя библиотека функции их там сколько -1, 2, 100 - ?.
Мы их спользуем и без проблем, но они нам понятны на все 100 потому что нами написанны и продуманны - Вот отсюда и вывод если надо сделать простой сайт а пока своего шаблонизатора нет можно спользовать smarty но при всем желании вы с первого скрипта не используете больше 10% его возможностей.
Smarty после обработки шаблонов создает обычный файл 1.php
<htm>
....
<? php echo $title;?>
</html>
- - - - --
Но чтобы описать данный файл надо создать шаблон 1.tpl
вызвать клас Смарти передать ему имя шаблона и переменую $title + в шаблоне с помощью языка смарти записать переменую {$title}
------------
Не ужели не проще сразу создать файл 1.html
В нем сразу написать
<htm>
....
<? php echo $title;?>
</html>

2) В скрипте где надо формируем перемую $title
3) Инклюдим файл шаблона
+ Мы не изучаем какойто специальный язык
+ Всю логику мы убираем с приложения
+ Если создать класс который при вызове будет принимать имя шаблона, + масив параметров (который мы распакуем перед подключениям шаблона) приложение стоновиться более мене не зависимо.

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

А вообще надо стараться все гда решить конкретную проблему а не искать супер универсальных решений - их про сто нет )
 

kvf77

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

Sam

Новичок
Demiurg
я тебя ни на какую сторону не привлекаю, просто фраза в тему )

что касается html_select_date - иногда это удобно, иногда неправильно, иногда и то, и то..

почему надо обязательно быть "категорически протов" или "категорически за"?
 

Domovoj

Guest
Автор оригинала: Фанат
Ребят, а как в ваших крутых шаблонах реализуется такая вещь, как выбор в форме даты с помощью трёх селектов.
и отметка выбранной из базы/текущей.

соответственно, контрольное задание - поменять шаблон вывода с "в линию" на "в столбик" и порядок следования инпутов с "d m y" на "y m d"
Наврено как и в обычных 2х уровневых системах - просто в 3ёх уровневых системах (бизнес-логика, логика отображения, шаблоны) сам код будет IMHO разделён так:
1. Бизнес-логика (PHP) - выборка данных, вычисления на основе этих данных
2. Логика отображения (PHP) - подготовка данных на основе классов/функций бизнес-логики, тут содержится деление на несколько столбиков, проверка настроек отображения данных, выбор, например, имени CSS файла и т.д.)
3. Шаблоны (не обязательно PHP - любой язык шаблонизаторов) - отображение данных, подготовленных в 2. Наверно должны содержать только логику перебора списков, и, может быть, условие для прятания невидимых блоков)

В итоге, за расположение отвечает 3. За выделение требуемых данных - 2. За общие функции выборки данных и связи - 1.

Нужно внешний вид поменять - правим 3.
Нужно какие-то новые данные выбирать для отображения (или как то по другому их выбирать), не изменяя логики - правим 2 + 3 (или только 2).
Меняем логику - править всё.

Соответственно для приведённого примера (поменять шаблон вывода с "в линию" на "в столбик" и порядок следования инпутов с "d m y" на "y m d") ничего нового вибирать/вычислять не надо, значит просто шаблон правим.


В принципе ничего не меняется по сравнению с 2я уровнями. Только логика подготивки данных (то самое деление данных на столбики и ряды) вынесено из шаблонов в отдельный уровень на PHP.

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

Только не надо сразу тухлыми помидорами кидать :) Я с этим только столкнулся и пытаюсь понять, даёт ли это что хорошего или нет.

-~{}~ 20.05.05 15:22:

Кстати, плюс такого подхода - использовать разные 2 с одним и тем-же 3. И наоборот.
 

Фанат

oncle terrible
Команда форума
"деление на несколько столбиков" - это "выделение требуемых данных"?
Вы, по-моему, сами путаетесь в своих уровнях.

-~{}~ 20.05.05 15:24:

Кстати, плюс такого подхода - использовать разные 2 с одним и тем-же 3. И наоборот.
не бывает.
МИФ
 

Domovoj

Guest
Автор оригинала: Фанат
"деление на несколько столбиков" - это "выделение требуемых данных"?
Вы, по-моему, сами путаетесь в своих уровнях.
Я неудачно выразился. Я имел в виду нечто такое:

1: выборка данных по условиям
2: подготовка данных к отображению:
- вызов 1 с указанем той части, которую надо выбрать (я это назвал "выделением", не знаю как ещё это назвать)
- подготовка массива столбцов
3: отображение этого массива


Автор оригинала: Фанат -~{}~ 20.05.05 15:24:


не бывает.
МИФ
А как такой пример?

Пусть есть шаблон для отображения списка продуктов (не всей страницы).

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

Они подготавлвиают данные по разному, но шаблон у них один.

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