Комментарии 12
имхо стало хуже читаться
+15
Чем хорош шаблон:
Имена классов и прочее в одном месте, а не раскиданы в конструкторах по коду.
Шаблон можно поменять / заменить, а код надо переписывать.
По коду сложно вообразить будущее форматирование / разметку.
Продолжать можно дальше)
Имена классов и прочее в одном месте, а не раскиданы в конструкторах по коду.
Шаблон можно поменять / заменить, а код надо переписывать.
По коду сложно вообразить будущее форматирование / разметку.
Продолжать можно дальше)
+4
Вашу библиотеку нельзя сравнивать с шаблонизаторами, которые призваны отделять логику от представления.
Что касается удобности и переиспользуемости — чем больше библиотека берет на себя, тем меньше гибкости остается. Атрибуты, теги — все это удобнее редактировать как раз в виде хтмл.
Ну и как то много телодвижений вы предлагаете на замену обычному циклу :)
Что касается удобности и переиспользуемости — чем больше библиотека берет на себя, тем меньше гибкости остается. Атрибуты, теги — все это удобнее редактировать как раз в виде хтмл.
Ну и как то много телодвижений вы предлагаете на замену обычному циклу :)
0
>Вашу библиотеку нельзя сравнивать с шаблонизаторами, которые призваны отделять логику от представления.
И в каком примере у меня не отделена логика от представления?
>Ну и как то много телодвижений вы предлагаете на замену обычному циклу :)
То есть совсем не видно что defaultUl практически один в один повторяет логику шаблона, которую к тому же можно повторно использовать?
И в каком примере у меня не отделена логика от представления?
>Ну и как то много телодвижений вы предлагаете на замену обычному циклу :)
То есть совсем не видно что defaultUl практически один в один повторяет логику шаблона, которую к тому же можно повторно использовать?
-1
0
Я думаю
немного читабельней
И судя по исходникам никакого подобия fluent интерфейса там нет, и реализация
будет проблематичной.
input.Type('submit').Value('Add to Cart')
немного читабельней
input({type: 'submit', value: 'Add to Cart'})
И судя по исходникам никакого подобия fluent интерфейса там нет, и реализация
function defaultUl(items, trans)
будет проблематичной.
0
Насчет читабельности — ИМХО на любителя. По мне JAML — читабельнее. Особенно когда eсть вложенность (как для статики, так и для заполнения шаблона данными). + у JAML явная реюзабельность шаблонов просто из коробки
fluent… а нужен ли он?
Проблем с defaultUl — нет никаких совсем. В добавок к этому при реализации ее с помощью Jaml получим реюзабельные шаблоны.
fluent… а нужен ли он?
Проблем с defaultUl — нет никаких совсем. В добавок к этому при реализации ее с помощью Jaml получим реюзабельные шаблоны.
0
defaultUl это и есть реюзабельный шаблон, у меня для этого используются просто функции, у него же какая то система регистраций, плюсы которой я не осознал. Fluent нужен для того что бы в дальнейшем была возможность кастомизировать то что получается на выходе из шаблона.
например после того как я получить
я могу легко добавить какие либо атрибуты.
как вы это сделаете с помощью jaml?
Можете привести пример реализации шаблона для ul по типу defaultUl(items, trans) и с генерировать соответствующий хтмл из примера?
например после того как я получить
var ul = defaultUl(items);
я могу легко добавить какие либо атрибуты.
ul.Class("something");
как вы это сделаете с помощью jaml?
Можете привести пример реализации шаблона для ul по типу defaultUl(items, trans) и с генерировать соответствующий хтмл из примера?
0
Вот табличка с персонами…
Jaml.register('table', function(personBook) {
table(
tr(th('Name'), th('Balance')),
Jaml.render('tableItem', personBook.persons);
);
});
Jaml.register('tableItem', function(person) {
tr(
{cls: person.balance<0?'red':'green', id: person.id },
td(person.name),
td(person.balance)
);
});
Jaml.render('table', personBook);
// personBook = { persons: [ Your array here ] };
Вот UL
Jaml.register('defaultUl', function(itemsContainer) { // Это вместо defaultUl
ul(Jaml.render(itemsContainer.desiredTamplateName, itemsConteiner.items); // Так можно заменить трансформацию.
});
Jaml.register('li-item', function(item) {
li({id: item.id }, item.name);
});
Jaml.render('defaultUl', { desiredTemplateName: 'li-item', items: [] );
Да, различие есть, нет вашей функции трансформации. Но это имхо не всегда плюс, получается очень размазанная по коду шаблонизация (один шаблон и куча разных функций трансформации). В случае JAML да, придется вместо каждой трансформации зарегистрировать свой шаблон элемента.
Jaml.register('table', function(personBook) {
table(
tr(th('Name'), th('Balance')),
Jaml.render('tableItem', personBook.persons);
);
});
Jaml.register('tableItem', function(person) {
tr(
{cls: person.balance<0?'red':'green', id: person.id },
td(person.name),
td(person.balance)
);
});
Jaml.render('table', personBook);
// personBook = { persons: [ Your array here ] };
Вот UL
Jaml.register('defaultUl', function(itemsContainer) { // Это вместо defaultUl
ul(Jaml.render(itemsContainer.desiredTamplateName, itemsConteiner.items); // Так можно заменить трансформацию.
});
Jaml.register('li-item', function(item) {
li({id: item.id }, item.name);
});
Jaml.render('defaultUl', { desiredTemplateName: 'li-item', items: [] );
Да, различие есть, нет вашей функции трансформации. Но это имхо не всегда плюс, получается очень размазанная по коду шаблонизация (один шаблон и куча разных функций трансформации). В случае JAML да, придется вместо каждой трансформации зарегистрировать свой шаблон элемента.
0
С помощью JAML замену атрибутов после генерации сделать не удастся, это так.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Javascript fluent html builder