Шаблонное представление версус программерское

tipnote

Поясню:



...Doctype

<html>

<body>

<hren onclick="return klaccc;">hren'</hren>

...

...

print render(template)

версус



doc = Document

hren = Hren("hren'")

hren.onClick = return(klaccc

doc.body.append(hren)

...

print doc

Вот у меня с некоторых пор начало складываться мнение, что чем сложнее интерфейс и проект, тем больше логика начинает превалировать над представлением и тем сильнее заметны всякие косяки, через которые реализован шаблонный язык логики. Вплоть до того, что шаблонное представление нужно "выкидывать" и переходить к "программированию" интерфейсов через виджеты.
Какие у кого мнения на этот счет?
ЗЫ Да-да, от верстальщиков тоже приходится "отказываться" в пользу программистов гуи.

Hastya

Шаблоны - отстой. Это, кстати, одна из причин, почему PHP скоро умрет.

Fragaria

Два бездоказательных и неочевидных утверждения.

ermsoft

А шаблоны на xslt ты к какой категории относишь?

tipnote

Не имею большого опыта с xslt, может, я чего пропустил. Чем принципиально xslt-преобразования отличаются от прогерского функционала любого мощного шаблонизатора?

Hastya

А шаблоны на xslt ты к какой категории относишь?

XSLT - отстой. Кстати, это не шаблоны.

slonishka

На мой взгляд, у XSLT есть три существенных минуса:
1) XML-синтаксис. XML вполне приемлим для разметки естественного текста: достаточно посмотреть на TeX или исходники man'ов, чтобы понять, что при таком применении XML визуально смотрится на том же уровне. Но использовать XML для языка программирования - это перебор. Лично я не могу прочитать даже свой XSLT-код уже через полчаса. Я не хочу пользоваться графическим редактором и мне не надо обрабатывать XSLT другим XSLT. Я хочу просто писать код в терминале.
2) Скудость средств. Странные переменные и рекурсия вместо цикла - это, конечно, красиво с академической точки зрения, но мне-то нужно программировать, а не считать числа Фибоначчи. Нет регулярных выражений (интересно, какой вообще бэкграунд создателей XSLT - Lisp and Java only ? нет много чего - не случайно появление EXSLT и разнообразных расширений (часто несовместимых) в каждом XSLT-процессоре. DTD и Xpath отделены от XSLT примерно так же, как C-препроцессор отделён от C, то есть, в общем-то вместе всё работает, но есть ситуации, когда нужно помнить, что это разные вещи. Я не понимаю, зачем это нужно в 21 веке.
И все эти претензии не высосаны из пальца, а появились в результате использования XSLT на моём сайте: он хранится в XML и с помощью XSLT превращается в статический HTML. И честно говоря, я не знаю, на что можно перейти. Хорошо хоть XSLScript избавляет от радости видеть натуральный XSLT.
3) По отзывам, парсеры XSLT медленные.
Я понимаю, если бы он был медленный, но на нём было бы лёгко писать, как на <вставьте свой любимый скриптовый язык>, но этого нет, см. пункты 1 и 2. Я понимаю, если бы он был супер-быстрый, как ассемблерные вставки, тогда можно было бы примирится с его нечитабельностью и ограничениями, но он медленный, см. пункт 3.
На мой взгляд, единственное место, где XSLT смотрится естественно, это в книжках про XSLT в разделе "Getting started".

ermsoft

Я не знаю хорошо ни одного классического шаблонизатора, признаться

Ну там, smarty видел совсем краем глаза, и template toolkit перловый пробовал.
Зато я могу ссылку на доклад по теме дать.
Коротко - обычные шаблонизаторы императивны, а xslt - функциональный язык.

slonishka

> Я не знаю хорошо ни одного классического шаблонизатора
> Коротко - обычные шаблонизаторы императивны

ermsoft

На мой взгляд, у XSLT есть три существенных минуса:
1) XML-синтаксис. XML вполне приемлим для разметки естественного текста: достаточно посмотреть на TeX или исходники man'ов, чтобы понять, что при таком применении XML визуально смотрится на том же уровне. Но использовать XML для языка программирования - это перебор. Лично я не могу прочитать даже свой XSLT-код уже через полчаса. Я не хочу пользоваться графическим редактором и мне не надо обрабатывать XSLT другим XSLT. Я хочу просто писать код в терминале.

Вообще да, у XML ужасный синтаксис.

2) Скудость средств. Странные переменные и рекурсия вместо цикла - это, конечно, красиво с академической точки зрения, но мне-то нужно программировать, а не считать числа Фибоначчи. Нет регулярных выражений (интересно, какой вообще бэкграунд создателей XSLT - Lisp and Java only ? нет много чего - не случайно появление EXSLT и разнообразных расширений (часто несовместимых) в каждом XSLT-процессоре. DTD и Xpath отделены от XSLT примерно так же, как C-препроцессор отделён от C, то есть, в общем-то вместе всё работает, но есть ситуации, когда нужно помнить, что это разные вещи. Я не понимаю, зачем это нужно в 21 веке.

Какая есть альтернатива? Заставить php/perl/python-программиста печатать HTML? Если в шаблонизатор унести еще и регэкспы и обработку входных данных, то верстальщикам придется выполнять еще больше работы, которую должны бы были выполнять поставщики данных - разработчики.

И все эти претензии не высосаны из пальца, а появились в результате использования XSLT на моём сайте: он хранится в XML и с помощью XSLT превращается в статический HTML. И честно говоря, я не знаю, на что можно перейти. Хорошо хоть XSLScript избавляет от радости видеть натуральный XSLT.

Тут автор признается, что и сам не знает альтернативы XSLT =)
Про XSLScript я не слышал, но если это подмена xml-синтаксиса чем-нибудь более удобным, то всецело поддерживаю это направление в развитии. Но XSLT от этого другим языком не станет.

3) По отзывам, парсеры XSLT медленные.
Я понимаю, если бы он был медленный, но на нём было бы лёгко писать, как на <вставьте свой любимый скриптовый язык>, но этого нет, см. пункты 1 и 2. Я понимаю, если бы он был супер-быстрый, как ассемблерные вставки, тогда можно было бы примирится с его нечитабельностью и ограничениями, но он медленный, см. пункт 3.
На мой взгляд, единственное место, где XSLT смотрится естественно, это в книжках про XSLT в разделе "Getting started".

Думаю, то, что с помощью XSLT верстается бОльшая часть сервисов яндекса, является достаточной success story

Я не пытаюсь утверждать, что XSLT - совершенство, но ничего сильно лучше для *больших* веб-приложений тоже нет. Просто сама предметная область сложная - преобразовывать данные в одном заданном формате (неважно там, свалка переменных или xml) в другой (html + css + гибко этот результат изменять в зависимости от требований менеджера или настроек пользователя). И простого решения тут быть не может.
А сказать "раз не получается поделить обязанности между разработчиком и верстальщиком, пусть один человек все делает" - точно не решение.

ermsoft

А что, не угадал?
Просто первую часть ответа я написал до того, как нашел ссылку на доклад veged'а, а вторую часть после

ermsoft

XSLT - отстой. Кстати, это не шаблоны.

XSLT - это язык преобразований XML. Преобразования записываются в виде шаблонов. Так что "шаблоны на XSLT" - вполне корректное выражение, хотя и в том, чтобы называть XSLT шаблонизатором, тоже ничего плохого не вижу.

tipnote

Посмотрел. Я не хочу программировать на этом :crazy:

Я так понял, это родили только ради XML?
В общем, с одной стороны это не классический шаблонизатор точно. А с другой это такой же недоязык, как и все, что есть в шаблонизаторах.
ЗЫ Это тупо первое впечатление.

tipnote

аставить php/perl/python-программиста печатать HTML

Перейти к объектной модели (O*M) и забыть о существовании HTML в 95% случаев?

slonishka

А что, не угадал?
Просто первую часть ответа я написал до того, как нашел ссылку на доклад veged'а, а вторую часть после

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

ermsoft

Перейти к объектной модели (O*M) и забыть о существовании HTML в 95% случаев?

Что такое O*M?
Кто верстать-то будет в итоге? Ты же не думаешь, что разработчик сможет в программерском представлении распечатать такой HTML (не зная при этом, что он печатает HTML что останется только css написать?

Hastya

Думаю, то, что с помощью XSLT верстается бОльшая часть сервисов яндекса, является достаточной success story

Учитывая, какая каша из языков используется Яндексом, использование XML там вполне себе нормально. Нормально для Яндекса.

tipnote

Что такое O*M?
Кто верстать-то будет в итоге? Ты же не думаешь, что разработчик сможет в программерском представлении распечатать такой HTML (не зная при этом, что он печатает HTML что останется только css написать?

Маппер свалки css+html+(возможно)js в объекты языка, на основе которого, например, будут строится уже виджеты. Или он будет маппить уже в виджеты.
Я думаю, что наиболее представление-емкую часть - шаблон скелета по дизайну - может сделать верстальщик. После чего смело идти домой, так как непосредственно GUI займется разработчик гуи, который в 95% случаев никогда не произнесет страшное слово HTML.
И да, я думаю, программировать эти активные куски гуя он будет через layout managers, а уж какими ухищрениями эти managers будут пользоваться при построении - цссом ли, джээсом ли - этот человек будет знать в 5% процентах случаев.
Вообще, не вырывайся из контекста. Там четко описано, когда шаблоны перестают удовлетворять _моим_ потребностям.

ermsoft

О, стало намного понятнее, и появилась куча вопросов.
Такой подход где-нибудь уже реализован? Django, Rails, нет?
Виджеты все равно придется описывать какими-то шаблонами? Причем более сложными, чем обычные, потому что они должны будут не только подставлять данные в нужные места, но и предоставлять методы для работы с ними, чтобы рвзработчик гуи потом смог сделать всякие там doc.body.append(...)?
И третий вопрос, кто будет склеивать разные виджеты в целую страницу? Написать общий layout manager, в который можно уложить любые виджеты и сказать, где какой и как они друг друга обтекают, допустим - наверное должно быть сложно. (хотя может я преувеличиваю).
Вообще звучит заманчиво.

Hastya

Такой подход где-нибудь уже реализован? Django, Rails, нет?

GWT, Tapestry, ThinWire, например. GWT обходится без шаблонов.

ermsoft

Посмотрел, энтузиазма поубавилось

GWT генерирует одну строку html и совершенно нечитаемый js, а книга по Tapesty на первых 50 страницах состоит из 50 строк кода и 200 картинок "нажмите в eclipse сюда, напишите для tomcat конфиг вот так".
Не люблю кодогенерацию

tipnote

Виджеты все равно придется описывать какими-то шаблонами? Причем более сложными, чем обычные, потому что они должны будут не только подставлять данные в нужные места, но и предоставлять методы для работы с ними, чтобы рвзработчик гуи потом смог сделать всякие там doc.body.append(...)?

Именно в силу кол-ва логики этих контролов я и предположил сначала маппить саму базу представления этих виджетов. То есть шаблонов вообще может не быть. Все строго на одном _нормальном_ языке.
Большинство случаев, имхо, можно легко уложить в десяток-другой не самых сложных layout managers. Тут стоит уже смотреть на подобный опыт чисто десктопных GUI фреймворков. А под сильно из*нутое расположение придется писать свой нештатный менеджер или расширение штатного менеджера. И тут да, уже пригодится рюхающий в верстке человек. Но вся фишка в том, что если все настолько из*нуто, то скорее всего это не насыщенная контролами система, а какой-нибудь лебедевский сайт, например. Это уже совсем из другой оперы - тут рулят шаблоны или в принципе ничего не рулит

tipnote

Посмотрел, энтузиазма поубавилось
GWT генерирует одну строку html и совершенно нечитаемый js, а книга по Tapesty на первых 50 страницах состоит из 50 строк кода и 200 картинок "нажмите в eclipse сюда, напишите для tomcat конфиг вот так".

Ага. Но это все решаемо, имхо (сам пытаюсь потихоньку родить что-то примитивное подобное для питона).

ermsoft

Ага.
В принципе со всем согласен, меня отталкивает то, что в итоге наружу наверняка будет отдаваться страшное месиво из html+js+css. Некрасиво.
Вот еще аргумент. Запросы пишут на sql, логика на python (допустим

верстка на html и клиентская логика на js не просто так, а потому что разные задачи удобнее решать на разных языках, которые для этого заранее предназначены. А если ты начнешь мапить все другие языки в питон, то или будешь обходиться урезанным набором операций, или конструкции получатся слишком громоздкими.
Ну как можно на питоне писать css?
Кто будет думать о хаках под разные браузеры?
Кто будет думать о том, что селекторы по id быстрее, чем селекторы по class'у?
В общем, пока ни у кого, насколько я понимаю, не получилось рабочего фреймворка, реализующего все это красиво.

slonishka

Думаю, то, что с помощью XSLT верстается бОльшая часть сервисов яндекса, является достаточной success story

вспомнил: http://www.rit2007.ru/paper_view.html?id=1165

Надя, надеюсь, вы не станете отрицать, что выбор технологии определяется комплексом факторов; зачастую имеющих слабое отношение к технической обоснованности применения этой самой технологии?
Я не спорю, что Яндекс.Маркет и "Вопросы Президенту" - высоконагруженные проекты. Меня коробит упоминание их как доказательств удобства, применимости и вообще крутизны технологии.
Я лично знаком с примером одного оператора сотовой связи, у которого _абсолютно_все_ сервисы, для которых требовалась SQL СУБД, использовали Oracle. Даже те, для которых всего-то была нужна одна-единственная таблица вида "ключ => значение". Потому, что таков корпоративный стандарт.

tipnote

Да, но, имхо, на большом числе задач эти языки запросов, языки разметок и проч и проч и проч хорошо покрываются функционалом мапперов.
На питоне не надо писать css. И js писать на питоне не надо (ну кроме разве что совсем примитивных конструкций типа return smth.func(... где smth некоторый объект в каком-то module.js, а параметры ... автопреобразуются из/в JSON).
В тех случаях, когда штатного функционала не хватает, чтобы расширяться не выходя за пределы языка, придется писать и sql запросы и css описания и js код. Это и так понятно.

ermsoft

Ага.
Способность держать нагрузку не имеет отношения к XSLT, на "Президенте" вообще все статикой генерировалось (Бобук тут рассказывал).
Под success story я пытался оспорить утверждение про "На мой взгляд, единственное место, где XSLT смотрится естественно, это в книжках про XSLT в разделе "Getting started"." - раз у яндекса получается его эффективно использовать, значит, не такая это ужасная технология

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

Оставить комментарий