Pull to refresh

Comments 61

Довольно неплохо, глубоко пока не вчитывался, однако Jinja2+Jython помоему лучший вариант для явы ( имхо конечно).

Ну и пока нету поддержки данного шаблонизатора различными IDE.

Чуть позже вникну, врядли оно лучше чем Jinja (не холивар)
Ну как всегда дело вкуса ))
Разница нашего движка в том что он на Java/PHP/JavaScript одинаково работает
Если память мне не изменяет Jade так же прекрасно работает на всех перечисленных языках. Может включите его в сравнение?
Да, возможно вы правы и нужно было его включить в сравнение. На наш взгляд Jade имеет несколько «нетрадиционный» синтаксис, существенно отличающийся от того что все мы привыкли видеть в таких шаблонизаторах как Smarty, Twig и т. д.
Я в основном работаю со Smarty, но в целом ничего особо удивительного в Jade для себя не открыл. Просто нужно немного привыкнуть.
А можно — ли каким либо образом заставить Jade генерировать не — HTML?
Спасибо за пример, но я имел несколько другое, возможно — ли с помощью Jade генерировать не структурированные текстовые данные?
К сожалению не могу ответить на ваш вопрос. Jade только изучаю.
Можно. Если каждую строку начинать с | :)
Мне кажется это не очень удобно.
Никто и не говорит, что HAML/Jade — панацея.
Тогда вам вопрос: а чем не угодил Twig? Делали ещё до него?
Twig это PHP — шаблонизатор, для нас важна кроссплатформенность.
Есть, как минимум, реализация для JS и очень похожий синтаксис в Django templates для питона.
Мне кажется, что если бы оно было полностью совместимо по синтаксису с twig/swig/django templates (с какими-то вашими дополнениями), ценности было бы гораздо больше. А то я что-то сомневаюсь, что вы под все редакторы будете писать подсветку/автокомплит:)
Конечно ничего не бывает сразу, но планы создания плагинов для популярных IDE у нас есть. Кроме того мы очень расчитываем на поддержку со стороны независимых разработчиков.
А есть план, как и чем заинтересовать сторонних разработчиков, чтобы они начали писать плагины под IDE?
Вы могли бы привести пример такой мотивации? В общем и целом мы открыты для подобных дискуссий.
Ну, например, почему есть подсветка синтаксиса джанго-шаблонов от vim'а до intellij? да потому что джанго — потому что много потенциально пользователей, потому что клевая вещь, потому что кажется простым. То есть — «Первое: я не один, всем это нужно, а если даже я не смогу, то есть кому подхватить упавшее знамя. Второе: это клевая вещь. Третье: да там делать нефиг, за вечер сделаю… за два… за неделю… выложу на гитхаб, там и код отрефачат и про баги напишут и сами починят».
.
IntelliJ-продукты, да. Ну и для vim пригодилось бы.
С виду синтаксис страшноват по сравнению с тем же Razor. Нет декораторов. Нет привязок к фреймворкам типа Spring.

Чем оно лучше Freemarker для server-side?
Тем, что FreeMarker не реализован под JavaScript, а это было одним из наших основных требований к шаблонизатору.
Про привязку для спринга завели тике в системе, хотим включить такую фичу в ближайшие планы
weblab.megafon.ru/issues/browse/HST-1

Про сервер-сайд — как уже сказал мой коллега, для нас основным требвоанием была реализация на javascript и java одновременно.

Декораторы — мы посмотрим как именно их можно реализовать в Histone. Сейчас это можно сделать на уровне кастомных пользовательских функций, но думаю в итоге мы реализуем это внутри самого движка.
Это здорово. Буду ждать какой-нибудь простой реализации декораторов и спринга.
Тоже подам голос за то, что интеграция со Spring MVC крайне необходима.
Использую Spring MVC+Freemarker. После знакомства c Twig пришло ощущение, что и Velocity, и Freemarker морально устарели. Лично мне больше больше всего не хватает наследования шаблонов и возможности писать свои фильтры. К тому же Freemarker излишне строг при обработке данных, передаваемых в шаблон. К примеру, ${route.number} вызовет ошибку, если из базы данных внезапно придёт null-овый номер маршрута. А если указать ${route.number!} то, может статься, ошибка в шаблоне возникнет, если объект маршрута из базы вообще получить не удалось. Всё это сильно нервирует и увеличивает затраты на отладку шаблонов.
sskorykh, про наследование ответил внизу — будет, но пока не готовы сказать когда

про фильтры — уточните плиз подробнее, или пример из любого другого движка — что именно нужно, как это должно работать?

обработка данных — тут могу сазать, что Histone сделан максимально устойчивым к неправильным данным. В совсем ошибку он вывалится либо если есть синтаксическая ошибка, либо в очень крайних случаях.

По вашему примеру ${route.number}
если переменной route не существует или она null или у неё нет свойства number, Histone вернёт результат типа undefined и продолжит выполнение шаблона дальше. Ошибки, остановившей выполнение, не произойдёт.
И что из мегафоновского веба уже реализовано на этом шаблонизаторе? Почему же именно шаблонизатор а не mobile или адаптивность?
На данный момент мы разрабатываем несколько проектов с использованием Histone и с удовольствием расскажем вам о них в следующих постах.
Планируются ли плюшки вроде декоратора, плагины для спринга?
Вы не могли бы пояснить что вы понимаете под «декоратором»? Плагины для спринга у нас в самом ближайшем будущем.
Про спринговые плагины:
уже сейчас есть работающий прототип, который позволяет в спринге вместо velocity/freemarker использовать Histone в качестве view. В ближайшее время доработаем его и выложим на гитхаб и напишем статью на хабр.

Про декораторы:
мы планируем реализовать декораторы, в стиле более близком к шаблонам play (Play Framework)
Окей, а когда это произойдет? С декораторами, интеграцией в Spring MVC и Spring Security я могу использовать ваш движок и возможно буду полезен в плане обратной связи. Freemarker конечно хороший, но весьма своеобразный =)
А о какой интеграции со spring-security идёт речь? всё таки Histone это шаблоны а не логика.
Это на уровне привязывания к спрингу, просто кидается Security Context в список глобальных объектов, доступных из шаблона. Просто пожелание =)
Понял вас
такое можно делать уже сейчас руками
при интеграции со Spring MVC это просто реализуем на автоматическом уровне
Kai, ответил вам чуть ниже, нечаянно попутал ветку.
В яндекс.почта используются клиент/серверные xslt преобразования. При подготовке данной статьи рассматривалась ли эта технология?
Рассматривалась, я лично большой поклонник XSLT, но при всех очевидных достоинствах данной технологии она имеет ряд существенных недостатков:
1. Браузер поддерживает лишь ограниченный функционал языка XSLT, а потому нужно быть очень аккуратным с тем, какие инструкции используются.
2. Браузер поддерживает лишь XSLT 1, в то время как на сервере возможно использование XSLT 2, возможности которого существенно шире.
3. На практике было выявлено, что XSLT гораздо сложнее в понимании дизайнерами шаблонов, а по нашему мнению именно они должны заниматься созданием и поддержкой шаблонов.
Невозможность выполнения кода напрямую из шаблона.

Вот это как раз правильно. Шаблон отделяет бизнес-логику от представления. В этом его предназначение. Как только появилась возможность выполнить код из шаблона, кто-то этим воспользуется. Со всеми вытекающими.
Наследование и декораторы фактически есть почти одно и тоже. И совершенно понятно что такой функционал нужен как минимум для конкурентоспособности нашего шаблонного движка.
Мы рассмотрим как и когда мы сможем реализовать такую функцию в Histone.
Кстати, в данный момент наследование может быть эмулировано при помощи макросов.
>«существует возможность с помощью специальной утилиты, входящей в состав продукта, скомпилировать исходный код шаблона в форму, исполнение которой будет происходить, минуя этап его разбора и парсинга»

А можно скомпилировать шаблон на языке php или java, потом передать скомпелированный шаблон клиенту и потом на языке javascript подставить данные и вывести результат?
Посмотрел документацию. Оказывается можно! Тогда это то что нужно. Осталось дождаться, когда структура этого откомпилированного шаблона (ast) будет выложена для всеобщего обозрения, чтобы можно было реализовать поддержку других языков. Мне, например, нужна еще поддержка .Net и, может быть, я бы принял участие в реализации этой поддержки.
Да вы абсолютно правы. Не могли бы вы пояснить что именно вам нужно от документации по структуре скомпилированного шаблона?
По сути мне нужна готовая реализация вашего проекта для .Net.
Если в ближайшее время вы планируете это сделать, то структура эта мне не нужна.
Если же это не планируется, то я размышляю о том, чтобы самостоятельно портировать движок с php или java на c#. С одной стороны я могу посмотреть эту структуру в существующих реализациях, но где гарантия, что пока я буду писать свой код у вас не поменяется эта структура? Поэтому желательно чтобы эта структура была задокументирована и неизменна (либо были версии) и чтобы в дальнейшем все могли пользоваться только этой структурой. И тогда, раз уж это открытый проект, я и другие разработчики могли бы опираясь на этот стандарт дополнять проект новыми реализациями.
Т.е. я хотел бы видеть некий сдандарт данных (желательно в JSON формате), которыми можно обмениваться между различными реализациями движка.
Ясно. Ближайших планов по портированию Histone на .Net у нас нет, но мы с радостью поможем вам портировать его. Мы можем создать документацию по формату скомпилированного шаблона за пару дней — это не проблема. Я отпишусь в этой ветке, как только это будет закончено.
humblegenius, если вы хотите сделать порт histone на c# но вам удобнее всего будет взять Java реализацию — дабы синтаксис наиболее близкий

спецификацию на формат AST мы подготовим до конца следующей недели

сейчас в нашей консоли сделаем вывод не только результата но и промежуточного AST дерева

плюс у нас в планах ещё несколько статей описывающих устройство histone изнутри — их планируем опубликовать в течении ближайшего месяца/двух

в гитхабе вы сможете найти приёмочные тесты, а в вики описание как ими пользоваться
в тестах есть проверки как для парсера так и для интерпретатора — на корректность AST и самого результата выполнения шаблона
Добавил отображение AST — шаблона в консоль. Для просмотра дерева скомпилированного шаблона, выберите из выпадающего списка «show result as» — «AST» и нажмите кнопку «Execute».
Я так понимаю, что проект развивается очень-очень медленно?
Проект развивается, на нем сейчас реализуем два проекта компании. Просто из-за большой загруженности не успеваем опубликовать что-то тут из нового.
В ближайшее время опубликуем и опишем связку Histone — Spring MVC — первую версию, но тем не менее работающую. Будет готова подсветка синтаксиса для IDEA (для некоторых редакторов подсветка уже есть. Также в течении месяца дополним Histone новыми функциями.
Постараемся оперативно собщить об этом на хабре :)
Какие новости по части Spring MVC + Histone?
Жаль что не видно жизни на проекте. Или все крутится внутри?
Почему вы так решили? Сейчас полным ходом идет рефакторинг первой версии, и мы готовимся выпустить следующую версию с гораздо более широким функционалом.
Если не секрет, как успехи?
Sign up to leave a comment.