Я тебя понял, мне просто кажется ты не проникся духом дата-биндинга :)

Проникся:) Именно поэтому я ввёл сахар {{}} (http://jsfiddle.net/NAPWB/7/), т.е. Snakeskin может сахарно генерить шаблон для либы, которая делает биндинг (у меня так и делает). Но в тоже время шаблоны у меня юзаются не только на клиенте, а также на сервере и т.д.

А в чем преимущества по сравнению с тем же RactiveJS, в котором есть все теже возможности шаблонизации (итерирование, условные операции, в.ч. для атрибутов {{ ? : }}, включение блоков, прекомпиляция)?

В наследовании, я бы и не начал писать Snakeskin, если бы например в Closure Templates был нужный функционал для наследования. Все остальные директивы просто являются уже обязательным джентельменским набором. В большинстве шаблонизаторов оно либо отсутствует в принципе (привет композиция из кучи подшаблонов), либо выполнено на детсадовском уровне (Dust, Handlebars и т.д.). Нужную мне гибкость давали только XSLT-основанные шаблоны, но меня тошнит от XSLT:) Поэтому я сделал по сути свою версию Google Closure Templates, который мне очень нравился, только в отличии от него Snakeskin работает примерно в 1000 раз быстрее (Google Closure Templates реально очень медленно работает), написан на JS, а не Java и реализует крайне мощный механизм наследования. Более того, Snakeskin писался и пишется под один конкретный проект. Ни одна из добавленных фич не была выдумана "сферически", а добавлена исходя из нужд проекта.

Snakeskin создан, чтобы использоваться не только в окошке браузера, а в любом окружении (это тоже были позаимстовано из Closure Templates). Я использую на сервере, также для генерации доки по jsDoc, для node-webkit приложений. Также Snakeskin дружит с Java.

К тому же, на клиенте Snakeskin не существует, т.к. он отваливается на этапе сборки проекта и мы работаем уже с простыми JS функциями, а для data-binding шаблонизатор нужен элементарный, но никак не 4.5к строк кода, которые в Snakeskin :)

почему? доступ к файлам шаблонов?

Если в кратце:

{template foo.bar()}
    hello!
{/}

Скомпилируется в

foo.bar = function () {
    return 'hello!';
};

И мы подключим скомпилиный файл как простой script и будем юзать, Snakeskin уже не нужен.

ЗЫ: разумеется это упрощение:)

Предварительная компиляция существенно быстрей, хотя и имеет ряд недостатков:
- время сборки и поддержка этой архитектуры (на этапе разработки желательно иметь проксю)
- объем передаваемых данных на клиент минимум на 30-40% больше (есть темплейтеры где эта цифра больше 1000%)

Грубо говоря:

{template foo(data)}
    {forEach data => value, index}
         <p>{value}</p>
    {end}
{/}

Будет транслировано в:

var foo = function (data) {
    var html = '';

     data.forEach(function (value, index) {
          html += '<p>'  + value + '</p>';
     });
    
     return html;
};

неплохо! наверное этот вопрос уже задавался, но .. а если мы получили с сервера неоткомпиленный шаблон?

Откомпиль его на клиенте, скорость трансляции в Snakeskin очень высокая, но придётся дополнительно грузить транслятор, а это 11 дополнительных килобайт (под гзипом + минификация).

Такие ошибки должны выявляться на этапе разработки и тестирования.

К примеру, у нас шаблоны на дев-серверах все компилирется в на клиенте, а на тестовых серверах, собираются в сборки.

Ура!
После 2.5 недели работы я таки закончил новую версию :)
https://github.com/kobezzza/Snakeskin

Максимус.....?

Ты о чём?

....
....
не, наверное показалось

Чёто тебе везде максимус мерещится. Я не он, уверяю:)

жесть :) нетрудно в коммитах ориентироваться?

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

Коммиты почему то один Shaci делал.

Типо если одинаковая аватарка, то один человек? Хорош флудить не по теме.

Выпустил 2 хотфикса:D
Запилил плагин для grunt
https://github.com/kobezzza/grunt-snakeskin

Выпустил новую версию: 3.2.0.

1) Добавлена директива $forEach для совместной работы с Collection:

{$forEach [1, 2, 3] => el, i}
{end}

{$forEach [1, 2, 3] => {filter: ':el > 2'} => el, i}
{end}

2) Улучшена работы с пробельными символами;
3) Исправлены найденные ошибки.

ЗЫ: в пример в фидле подключил также Collection, что бы можно было потестить.

Выпустил версию 3.3.0

1) Добавлена новая директива interface, которая позволяет декларировать шаблоны, которые войдут в скомпилированный файл как пустые функции с входными параметрами;

{interface foo(a1, a2, a3)}
    ...
{end}

=>

function foo(a1, a2, a3) {}

Таким образом сейчас существует 3 директивы для декларации шаблона:

*) template - простая декларация шаблона;
*) interface - декларация шаблона, но в конечный JS войдёт только интерфейс;
*) placeholder - декларация шаблона доступного только на этапе трансляции.

2) Исправлены некоторые ошибки;
3) Улучшена обработка ошибок на этапе трансляции.

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

Не совсем понял, можно пример?

***

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

{template helloWorld(name = 'world')}
    <h1>Hello {name}!</h1>
{/template}
    
{old = helloWorld}
    
{template helloWorld()}
    {call @old()}
{/template}

http://jsfiddle.net/PqQ5w/2/
Uncaught TypeError: undefined is not a function

Гм, это баг, ща буду разбираться, спс за репорт

upd: хм, баг воспроизводится только в фидле, мистика :) А вообще так можно делать и так нужно делать, ибо это одна из самых первых фич которые я закладывал в шаблонку когда я её разрабатывал.

upd upd: это особенность работы в фидле и компиляции в живом режиме, мб придумаю как зафиксить.

***

Вот так работает, видимо из-за eval-ов в фидле глючит.

window.ns = {};
Snakeskin.compile(document.getElementById('templates'));
document.getElementById('test').innerHTML = ns.helloWorld();

tenshi, не совсем понял причём тут манифест аддонов к хрому, но кстати, выполнение eval там можно разрешить в том же манифесте, я писал в своём время аддоны к хрому (как для первой версии манифеста, так и для второй).

При том, что не во всех окружениях эвал разрешен. И вообще замыкания быстрее эвалов.

Кроме экстеншенов есть еще апликейшены, где говорят нельзя включить.

tenshi, ну дык, предварительная компиляция и никаких эвалов.

Тогда ок. Поделись инфой как такие вотчеры писать.

Да особо никакой инфы то и нет, т.к. я юзаю встроенный механизм WebStorm, а ему для работы просто нужно указать ссылочку на bash скриптик (или cmd для винды) и задать нужные параметры. Я легко освоил по примеру встроенных вотчеров.

***

Скоро закончу работу над очередным мажорным обновлением - Snakeskin 3.4. Добавил оч много вкусностей, планирую на след недели закончить.

Сейчас реализую альтернативный синтаксис декларации шаблонов, очень близкий к Jade / HAML для более удобной генерации XML-подобной структуры.

/// Новый синтаксис активизируется путём простой декларации 
/// без каких либо специальных флагов и работает совместно со старым

- template hello(name)
  h1.bar hello {name}!

{template child() extends hello}
  ...
{/}

Благодаря раздельной модульной архитектуре парсера / транслятора добавить новый синтаксис очень просто и он будет поддерживать 100% оригинальных возможностей Snakeskin, т.е. супер мощная система наследования и фильтров, богатый набор итераторов, включая интеграцию с Collection на уровне синтаксиса.

Ещё заметным обновлением является интеграция на уровне синтаксиса с фреймворком Async и нативной реализацией Promise, а также общий асинхронный интерфейс для написания асинхронных шаблонов.

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

и исчо layouts :)

Само собой:)

Для нового синтаксиса будет добавлена поддержка ссылки на родительский класс а ля Stylus.

.b-foo.&_checked_true
    span.&__master hello world!

=>

<div class="b-foo b-foo_checked_true">
    <span class="b-foo__master">hello world!</span>
</div>

Т.е. & будет ссылаться на последний класс без использования &.

***

Новый синтаксис будет прекрасно сосуществовать и со старым, т.е. если будет нужно, то например

- template foo()
    div fooo bar {call bar()} bla bla bla

Вопросик по движку есть.

1)
Правильно ли я понимаю что при изменении класса будет перегенерирован весь html ?

<div {attr 'class', a}></div>

2)
Правильно ли я понимаю что невозможно обратится к одному из свойств style к примеру opacity, а только ко всему style,
и опять же после изменения style весь html перегенерируется?

3)

<div>{test}</div>

А это тоже приведет к перегенерации html при изменении test?


Извини если вопросы глупые, мало знаком с твоим шаблонизатором.
Оцениваем возможность использования на клиенте.

Работа шаблонизатора состоит в 90% случаев только в обновлении style и атрибутов, процентах в 7% в изменени текстовых нод, и только в 3% случаев добавление удаление html тегов. Проценты на глазок конечно, просто чтобы обьяснить проблематику.

Буду благодарен за ответ

DjDiablo, мне кажется ты не понял концепцию моей шаблонки :)

Шаблон Snakeskin - это функция JavaScript, т.е. когда ты напишешь

{template foo(name)}
    Hello {name}!
{end}

То после трансляции будет

var foo = function foo(name) {
    var __SNAKESKIN_RESULT__ = '',
        $_;

    var TPL_NAME = 'foo';
    var PARENT_TPL_NAME;

    __SNAKESKIN_RESULT__ += ' Hello ';
    __SNAKESKIN_RESULT__ += Snakeskin.Filters.html(Snakeskin.Filters.undef(name));
    __SNAKESKIN_RESULT__ += '! ';

    return __SNAKESKIN_RESULT__;
};

Т.е. это простая функция, которая принимает параметры и плюётся текстом. Никакого data-binding нет и не спроста, т.к. это задача отдельного инструмента. Snakeskin поддерживает сахарный синтаксис для "пометок" для либы, которая будет делать data-binding.

{template foo(name)}
    <input value="{{value}}" />
{end}

А уже с полученным можно юзать любую либу биндинга, например Ractive. Так что Snakeskin - это именно шаблоны, которые сделаны очень качественно (чего не скажешь о блендерах вроде Angular) с охренительной поддержкой для code-reuse.

Пример использования на клиенте:

{template Select.prototype.render(name) extends Input.prototype.render}
    {block dropdown}
        ...
    {end}
{end}

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

Коротко суть.

***

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

Понял, то бишь он выплевывает только текст.
Выходит для клиента непригоден.

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

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

Как я понял snakeskin катит только для сборки статических страничек в стиле "справочник садовода любителя".
Стебусь конечно :)
Иными словами шаблонизатор формирует предельно статичный html, ибо полная замена новым html(в виде текста который выплюнет шаблонизатор) это безумно дорогая операция. Вся трибуха с фильтрами,условиями, циклами и даже сама шаблонизация получается бесполезной.Ну может за исключением случаев когда этим пользуются только однажды или очень очень редко. Единственное что на клиенте может быть полезно это наследование. Все вышесказанное касается только клиента, на сервере все окей.

Тем не менее спасибо за ответ.
P.S. плюсануть сорри не выходит.

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

Ну а вообще, я возможно прикручу такую фичу из коробки, раз всем её так хочется :)

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

Вставка текста и парсинг его браузером быстрее, чем создание DOM элементов через конструкторы.
Другое дело дата-биндинг и обработчики событий. Разумеется, нет смысла менять весь html, если требуется изменить значение атрибута style. Но, это уже дата-биндинг.

Дай линки на примеры