-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Преобразования данных, логика отображения. XSLT, template engines, альтернативы.
- Автор темы fixxxer
- Дата начала
korchasa
LIMB infected
Мы скорбимАвтор оригинала: fisher
круто. а ничего что blitzpack больше не существует?
А почему, если не секрет? Идея не парсить шаблон каждый раз вроде бы живая...или это с внутренней реализацией не сочетается? Заранее извиняюсь, просто только сейчас в исходники полез, и сходу разобраться в 3700 строчках кода тяжеловато.
Попытки оживить pack на версии 0.5.4 пока ни к чему не приводят
fisher
накатила суть
>>пока ни к чему не приводят
я на память не помню с какой версии я это выкинул. причин несколько
1) добавлено это было в старой версии ещё не поддерживающий даже контексты и быстро перестало работать с нововведениями
2) как ни странно это давало совсем небольшой выигрыш - сам парсинг у блица довольно быстрый а вот реализация загрузки бинарных данных наверное можно было реализовать круче, в любом случае надо садиться и много думать
3) пользовались этим единицы а кода много
4) ещё до появления blitzpack было несколько более заманчивых идей по реализации кеширования которые более эффективны, поэтому если возвращаться к вопросу - надо брать их (кеширование структуры шаблона в шаред мемори чтоб при инициализации хватило лишь поставить указатель и всё)
я на память не помню с какой версии я это выкинул. причин несколько
1) добавлено это было в старой версии ещё не поддерживающий даже контексты и быстро перестало работать с нововведениями
2) как ни странно это давало совсем небольшой выигрыш - сам парсинг у блица довольно быстрый а вот реализация загрузки бинарных данных наверное можно было реализовать круче, в любом случае надо садиться и много думать
3) пользовались этим единицы а кода много
4) ещё до появления blitzpack было несколько более заманчивых идей по реализации кеширования которые более эффективны, поэтому если возвращаться к вопросу - надо брать их (кеширование структуры шаблона в шаред мемори чтоб при инициализации хватило лишь поставить указатель и всё)
Alexandre
PHPПенсионер
думаю, что это можно организовать, если склонировать XMLDomDocument шаблона в шаредмемори, а потом либо его склонировать обратно, либо использовать объект прям из шаредмемори. Надо на досуге поэксперементировать. Думаю, клонирование будет быстрее, чем сюреализация/десюреализация. А вот как с файлами быть - я пока не знаю.
-~{}~ 24.01.08 17:06:
как сделать упаковку бинарного дерева в выделенную область - я приблизительно представляю, остается лишь продумать детали.
ради полноценного отделения view я вполне согласен поступиться производительностью. на приемлемом уровне конечно. json и некий шаблонизатор это кстати от чего я отталкивался 
, но сейчас по мере размышлений склоняюсь к тому что в этом шаблонизаторе я просто погрязну на века, и с точки зрения getting things done xslt оптимально.
, но сейчас по мере размышлений склоняюсь к тому что в этом шаблонизаторе я просто погрязну на века, и с точки зрения getting things done xslt оптимально.
мм, скинь в личку... я правда совсем не уверен что у нас с тобой схожие задачи
-~{}~ 29.01.08 06:38:
наверное стоит поднять тему ибо чувствую некоторое недопонимание.
тут ведь какое дело-то. Вот есть у нас приложение, MVC все дела ясное дело, ну и что делает какой нибудь $products->get(), ясное дело отдает данные в наиболее естественном формате рекордсета, и ему ясное дело наплевать на то, как это все дело надо оформить и вывести, ибо иначе это черт знает что а не нормальная архитектура. Контроллеру на проблемы вывода тоже глубоко плевать, он знает какие параметры передать в этот get (скажем лимит-оффсет), а уж как это все выводится и с какими рюшечками его это ну никак не волнует, иначе это тоже черт знает что. Это все дело view.
А что такое view - это как и все у нас, алгоритмы и данные, то есть презентационная логика и шаблон+полученные входные данные. А тут уже есть разные подходы. Можно взять и тупо все перемешать на php, smarty или whatever, со всеми прелестями спагетти стайл. Можно взять и более элегантно все перемешать, придумав язык программирования с xml-синтаксисом (ну вы поняли). Можно все честно разделить - вот тут у нас шаблон, вот тут у нас вью-логика (почти так сделаны blitz/php-templates, хотя в чистом виде это был бы голый xhtml + вьюха, работающая с ним посредством какого-нибудь xquery и dom).
Вопрос выбора здесь, на самом деле, прежде всего организационный - то есть кто пишет шаблон, кто пишет код, и сколько это в сумме человек =). И если все делается одной командой, то тут и спорить нечего что лучше всего когда верстальщик верстает, а программист программирует - и минималистичные движки типа blitz тут подходят прекрасно - программист с верстальщиком всегда договорятся, что куда итерируется и это будет эффективнее и быстрее, чем "а чо, я данные отдал, пускай вася там делает", а бедный вася, фтыкая в супер-макет с овальным деревом в три с половиной колонки, третий уже день как строит монстрообразные конструкции на чем-там-у-него. Другое дело - и уже более сложная задача - если дизайн навешивается извне, будь то партнерская сеть или просто огромная корпорация (монстров) с кучей подразделений и зоопарком технологий - и все что есть это сериализованные наборы данных. Н утут что делать. XSLT, да, разумеется. Если вы яндекс, которому ничего не стоит набрать армию xslt-рабов. А бедный партнер, зарегистрировавшийся в надежде загнать в систему трафик и срубить свои процентики, с трудом верстающий на ядреной смеси дивов, таблиц и такой-то матери, вполне может и ниасилить.
Ну вот собственно разрисовал гипотетическую ситуацию, а вопросы они уже все сформулированы =).
-~{}~ 29.01.08 06:38:
наверное стоит поднять тему ибо чувствую некоторое недопонимание.
тут ведь какое дело-то. Вот есть у нас приложение, MVC все дела ясное дело, ну и что делает какой нибудь $products->get(), ясное дело отдает данные в наиболее естественном формате рекордсета, и ему ясное дело наплевать на то, как это все дело надо оформить и вывести, ибо иначе это черт знает что а не нормальная архитектура. Контроллеру на проблемы вывода тоже глубоко плевать, он знает какие параметры передать в этот get (скажем лимит-оффсет), а уж как это все выводится и с какими рюшечками его это ну никак не волнует, иначе это тоже черт знает что. Это все дело view.
А что такое view - это как и все у нас, алгоритмы и данные, то есть презентационная логика и шаблон+полученные входные данные. А тут уже есть разные подходы. Можно взять и тупо все перемешать на php, smarty или whatever, со всеми прелестями спагетти стайл. Можно взять и более элегантно все перемешать, придумав язык программирования с xml-синтаксисом (ну вы поняли). Можно все честно разделить - вот тут у нас шаблон, вот тут у нас вью-логика (почти так сделаны blitz/php-templates, хотя в чистом виде это был бы голый xhtml + вьюха, работающая с ним посредством какого-нибудь xquery и dom).
Вопрос выбора здесь, на самом деле, прежде всего организационный - то есть кто пишет шаблон, кто пишет код, и сколько это в сумме человек =). И если все делается одной командой, то тут и спорить нечего что лучше всего когда верстальщик верстает, а программист программирует - и минималистичные движки типа blitz тут подходят прекрасно - программист с верстальщиком всегда договорятся, что куда итерируется и это будет эффективнее и быстрее, чем "а чо, я данные отдал, пускай вася там делает", а бедный вася, фтыкая в супер-макет с овальным деревом в три с половиной колонки, третий уже день как строит монстрообразные конструкции на чем-там-у-него. Другое дело - и уже более сложная задача - если дизайн навешивается извне, будь то партнерская сеть или просто огромная корпорация (монстров) с кучей подразделений и зоопарком технологий - и все что есть это сериализованные наборы данных. Н утут что делать. XSLT, да, разумеется. Если вы яндекс, которому ничего не стоит набрать армию xslt-рабов. А бедный партнер, зарегистрировавшийся в надежде загнать в систему трафик и срубить свои процентики, с трудом верстающий на ядреной смеси дивов, таблиц и такой-то матери, вполне может и ниасилить
.Ну вот собственно разрисовал гипотетическую ситуацию, а вопросы они уже все сформулированы =).
atv
Новичок
И всё-таки XSLT. Ведь на самом деле партнёру не придётся создавать шаблон с нуля, ему достаточно будет только подправить существующий, и то не весь, а какую-то часть. А найти эту часть в хорошо структурированном шаблоне XSLT, да ещё с комментариями, будет гораздо легче чем в том-же Smarty подобном шаблоне, только нужно убрать логику из шаблона.
dark-demon
d(^-^)b
fixxxer, выводы забыл
StUV
Rotaredom
fixxxer
имхо, смарти, натив, xslt, blitz - все это одно и то же
"тут убрал, там добавил"...
логика представления всегда останется программируемой
+ с учетом усложнения дизайна в последнее время - ее будет становиться все больше и больше
а выбор конкретной технологии обсуловлен опытом, уровнем знаний, "фазой луны" и тп...
м.б. когда-нить (в хтмл 12.0) появятся "идеально настраиваемые хтмл-контролы" из которых можно будет собрать любой сайт выставляя только атрибуты "цвет/размер/..."
имхо, смарти, натив, xslt, blitz - все это одно и то же
"тут убрал, там добавил"...
логика представления всегда останется программируемой
+ с учетом усложнения дизайна в последнее время - ее будет становиться все больше и больше
а выбор конкретной технологии обсуловлен опытом, уровнем знаний, "фазой луны" и тп...
м.б. когда-нить (в хтмл 12.0) появятся "идеально настраиваемые хтмл-контролы" из которых можно будет собрать любой сайт выставляя только атрибуты "цвет/размер/..."
StUV
Rotaredom
я про то, что сейчас разнообразие сайтов не сравнимо с сис.-гуи - и в ближайшее время "унификация веб-интерфейсов" не намечается
+
"вебдваноль" уже часто переводит бизнес-логику в логику представления, из-за чего само понятие "верстка" уже устаревает
верстальщики становятся "программистами интерфейсов" - поэтому выбор конкретного средства шаблонизации зависит скорее от вопросов производительности, чем от утопичной проблемы разделения "логики и представления"
dark-demon
d(^-^)b
какие проблемы сделать mvc на клиенте?