Комментарии 30
автор несколько замечаний по статье: исправьте «преступим» и картинки с текстом стоило делать в png, сейчас они явно показывают насколько jpeg ущербен при работе с текстом
по поводу статьи, ничего не скажу про процесс создания компонентов, мне показалось что это очень трудоемко, но может быть я ошибаюсь. Одно хотел спросить, как вы замеряли скорость работы jQuery vs jsForms vs DOM любопытно взглянуть, отчего это jQuery в разы проигрывает.
еще хотел сказать, «живой пример» очень недружелюбный, я например не понял что и как там делать, а главное зачем…
не могли бы вы сделать пару страниц с примерами по-проще?
по поводу статьи, ничего не скажу про процесс создания компонентов, мне показалось что это очень трудоемко, но может быть я ошибаюсь. Одно хотел спросить, как вы замеряли скорость работы jQuery vs jsForms vs DOM любопытно взглянуть, отчего это jQuery в разы проигрывает.
еще хотел сказать, «живой пример» очень недружелюбный, я например не понял что и как там делать, а главное зачем…
не могли бы вы сделать пару страниц с примерами по-проще?
Картинки делал в png, хостер картинок зачем-то перевел их в jpg.
Тесты доступны, зайдите на страницу и увидите их реализацию, пост и так перегружен кодом, так что я решил убрать их реализацию.
Трудоемкость написания шаблонов, да это так, но специально для этого и разрабатывался сайт конструктор, он сам является примером данного подхода.
Тесты доступны, зайдите на страницу и увидите их реализацию, пост и так перегружен кодом, так что я решил убрать их реализацию.
Трудоемкость написания шаблонов, да это так, но специально для этого и разрабатывался сайт конструктор, он сам является примером данного подхода.
я пытаюсь разобраться в тестах. подскажите:
for (var i = 0; i < opts.Count; i++) {
var tmp = $(jsForms.Templates.Menu);
var tmp1 = $('.menu-text',tmp);
tmp1.text(opts.BlankText);
//cont.append(tmp);
}
почему нельзя сделать так:
for (var i = 0; i < opts.Count; i++) {
var tmp1 = $('.menu-text', jsForms.Templates.Menu);
tmp1.text(opts.BlankText);
//cont.append(tmp);
}
этим немного мы экономим, не так ли?
for (var i = 0; i < opts.Count; i++) {
var tmp = $(jsForms.Templates.Menu);
var tmp1 = $('.menu-text',tmp);
tmp1.text(opts.BlankText);
//cont.append(tmp);
}
почему нельзя сделать так:
for (var i = 0; i < opts.Count; i++) {
var tmp1 = $('.menu-text', jsForms.Templates.Menu);
tmp1.text(opts.BlankText);
//cont.append(tmp);
}
этим немного мы экономим, не так ли?
не пойму за что вам поставили минусы, автор не обращайте внимания, ваша статья очень интересная
а где графики?
ой, сейчас все показалось, сорри
Странно, должны быть, вот ссылка.
По структуре описания компоненты напоминают смесь WPF-ных стилей с темплейтами :)
Любопытная статья.
Любопытная статья.
НЛО прилетело и опубликовало эту надпись здесь
ну в принципе, правильно, только ExtJS я бы сказал, не совсем подходит, если вам надо одна форма на сайте или пару кнопок. Екст больше, чем система виджетов, это фреймворк для построения веб-приложений. вот когда у вас форм с десяток и они завязаны друг на друга — тогда есть. а просто на сайт вставить красивую форму обратной связи — это да, лучше использовать что-то полегче. Что бы не с пушки по воробьям было :)
А у меня вообще не было ощущения js — .NET…
что увидят пользователи без яваскрипта?
Маленький совет:
1. в таблицу стилей
div.js-template
{
display: none;
}
function getTemplate(id)
{
var r = $(id).html();
$(id).remove();
return r;
}
и все шаблоны HTML держите в коде страницы. Не засрояйте ими JavaScript.
А за материал — спасибо.
1. в таблицу стилей
div.js-template
{
display: none;
}
function getTemplate(id)
{
var r = $(id).html();
$(id).remove();
return r;
}
и все шаблоны HTML держите в коде страницы. Не засрояйте ими JavaScript.
А за материал — спасибо.
Да, поскольку концепция предполагает соответствие имён шаблонов и имен компонентов,
то просто надо убить Templates, А брать, например sub-divs из некоего предопределённого скрытого Div.
то просто надо убить Templates, А брать, например sub-divs из некоего предопределённого скрытого Div.
Насколько это будет быстро?
Проделав кучу тестов, было определено что с дом элементом надо как можно меньше взаимодействовать.
В вашем примере вы предлагаете получать из него innerHTML, а что я буду с ним дальше делать? Парсить? Тогда зачем делать лишние движения, если в Templates и так хранятся innerHTML. С другой стороны шаблоны будут лежать в HTML, но пользователю все равно, главное что бы быстро.
Проделав кучу тестов, было определено что с дом элементом надо как можно меньше взаимодействовать.
В вашем примере вы предлагаете получать из него innerHTML, а что я буду с ним дальше делать? Парсить? Тогда зачем делать лишние движения, если в Templates и так хранятся innerHTML. С другой стороны шаблоны будут лежать в HTML, но пользователю все равно, главное что бы быстро.
Естественно, речь идёт только о том, чтобы загружать сам шаблон из HTML-элемента, только когда его нет в кэше шаблонов. Тем более, надеюсь, шаблоны у Вас компилируются.
Почему полезно держать шаблоны в HTML-страницах — для удобства редактирования и разделения ролей дизайнера и программиста.
Почему полезно держать шаблоны в HTML-страницах — для удобства редактирования и разделения ролей дизайнера и программиста.
Идея хороша и даже в начале пути я использовал её, но от нее пришлось отказаться так как только несколько браузеров(FF3+,Safari,Chrome) поддерживают не стандартные теги(component, properties и т.д.) все остальные превращают их в «плоскую» структуру, это меня очень сильно огорчило и пришлось писать очень быстрый html парсер на js. Во общем то именно поэтому и пришлось делать редактор компонентов, через него можно разделить программистов и дизайнеров. А так я с вами полностью согласен, дизайнерам привычнее шаблоны держать в HTML.
Так ведь совершенно необязательно создавать новые тэги.
Вполне подходят существующие.
Например, вместо component — JSON here
Вполне подходят существующие.
Например, вместо component — JSON here
афайк, это не так. рекомендую к прочтению: d-o-b.ru/?article:kill.html
впрочем, хранить шаблоны в хтмл — не самая светлая идея, ибо: pastebin.mozilla-russia.org/93060
впрочем, хранить шаблоны в хтмл — не самая светлая идея, ибо: pastebin.mozilla-russia.org/93060
FF 3.0, Intel 2Ghz(правда не 2 ядра — обычный), ddr 2gb — тестовый пример повесил браузер, спустя 10 сек. попросило прервать скрипт или продолжить, нажал продолжить — и снова висит и через 10- сек тот же запрос.
Извините, но у меня нет и капли сомнения, что я этим пользоваться не буду.
Извините, но у меня нет и капли сомнения, что я этим пользоваться не буду.
Наверняка вы нажали на клавишу «Run tests», тесты запустились без паузы и браузер в панике написал что js «повис», так как продолжительность каждого теста около 6-7секунд. Запустите по отдельности тесты.
Да, я давно уже наблюдал такой эффект, нужно переделывать систему тестирования, что бы она запускала тесты через определенное время, что бы браузер мог «вздохнуть», но сами понимаете времени на все не хватает.
Да, я давно уже наблюдал такой эффект, нужно переделывать систему тестирования, что бы она запускала тесты через определенное время, что бы браузер мог «вздохнуть», но сами понимаете времени на все не хватает.
Почему ьы не посмотреть в сторону dojotoolkit? Очень похожие решения — я имею ввиду dijit.
тоже сталкивался с подобной проблемой, но шаблоны я заменил генерацией компонентов, другими словаи есть фабрика, которая по запросу создает и возвращает компоненты с указаной темой оформления
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
jsForms