Comments 67
Содержательно. Спасибо.
Отличная либа! Уже предвижу, в каких проектах и где ее можно применить
Удобно, но сеошники это не одобрят…
Не SEO единым… Есть еще и бизнес web apps.
А зачем это в бизнес web-apps? такие системы не являются настолько нагруженными что бы оптимизировать их выносом обработки фронтента на компьютер пользователя. Написание бекенда и фронтенда на разных системах шаблонизации такой же бред, усложняющий поддержку.
То есть остаются исключительно специфические web системы, которые опять же не настолько нагружены что бы тратить время программистов на отлавливание багов в шаблонах созданных таким способом.
Итог:
+ перенос нагрузки по формированию шаблона на сторону пользователя
— дополнительные навыки верстальщика и программиста
— сеошники это точно не одобрят
— дополнительные затраты времени отлавливание ошибок
То есть остаются исключительно специфические web системы, которые опять же не настолько нагружены что бы тратить время программистов на отлавливание багов в шаблонах созданных таким способом.
Итог:
+ перенос нагрузки по формированию шаблона на сторону пользователя
— дополнительные навыки верстальщика и программиста
— сеошники это точно не одобрят
— дополнительные затраты времени отлавливание ошибок
— дополнительные навыки верстальщика и программиста
4 часа на чтение и усвоение 6 листов документации
— сеошники это точно не одобрят
никто не обязывает, что вообще за глупость такая — использовать это публичной части. что надо курить, чтобы додуматься до этого?..
— дополнительные затраты времени отлавливание ошибок
что за глупость? чем отличается время поиска ошибок с использованием одного или другого шаблонизатора. здесь же нет сложной логики, просто вывод переменных. если ошибся с названием переменной, то в консоль выведется ошибка, что такой переменной нет, остается только найти ее с помощью ctrl+f. так же, если понимать во что компилируется этот шаблон, то есть возможность использовать и вывод в консоль, и трассировку и прочее.
просто признайтесь, что вам плагин просто не понравился. пора бы открыть глаза, на дворе 21 век.
4 часа на чтение и усвоение 6 листов документации
— сеошники это точно не одобрят
никто не обязывает, что вообще за глупость такая — использовать это публичной части. что надо курить, чтобы додуматься до этого?..
— дополнительные затраты времени отлавливание ошибок
что за глупость? чем отличается время поиска ошибок с использованием одного или другого шаблонизатора. здесь же нет сложной логики, просто вывод переменных. если ошибся с названием переменной, то в консоль выведется ошибка, что такой переменной нет, остается только найти ее с помощью ctrl+f. так же, если понимать во что компилируется этот шаблон, то есть возможность использовать и вывод в консоль, и трассировку и прочее.
просто признайтесь, что вам плагин просто не понравился. пора бы открыть глаза, на дворе 21 век.
— 4 часа на чтение и усвоение 6 листов документации
Это вы ответите тогда когда вам скажут через 2 часа все должно быть готово, какой смысл тратить это время, если этого можно не делать, да и потом еще получить проблемы с совместимостью.
— никто не обязывает, что вообще за глупость такая — использовать это публичной части. что надо курить, чтобы додуматься до этого?..
Покажите мне смысл писать для фронтенда и бекенда используя разные шаблонизаторы? меня вполне устраивает ajax подгрузка на бекенде.
— что за глупость? чем отличается время поиска ошибок с использованием одного или другого шаблонизатора…
Цитата с текста статьи: Дело в том, что jQuery Templates выполняет относительно простое преобразование текста шаблона, поэтому если вы допустите ошибку в выражении, то сообщение об ошибке будет относиться к тексту полученной в результате преобразования функции и часто может быть крайне невразумительным.
— просто признайтесь, что вам плагин просто не понравился. пора бы открыть глаза, на дворе 21 век.
Это не означает что все велосипедисты должны пересесть на газонокосилки
Статья интересная, технология интересная, я хотел сказать только то что это узкоспециализированное направление, и применять бездумно налево и на право не стоит.
Это вы ответите тогда когда вам скажут через 2 часа все должно быть готово, какой смысл тратить это время, если этого можно не делать, да и потом еще получить проблемы с совместимостью.
— никто не обязывает, что вообще за глупость такая — использовать это публичной части. что надо курить, чтобы додуматься до этого?..
Покажите мне смысл писать для фронтенда и бекенда используя разные шаблонизаторы? меня вполне устраивает ajax подгрузка на бекенде.
— что за глупость? чем отличается время поиска ошибок с использованием одного или другого шаблонизатора…
Цитата с текста статьи: Дело в том, что jQuery Templates выполняет относительно простое преобразование текста шаблона, поэтому если вы допустите ошибку в выражении, то сообщение об ошибке будет относиться к тексту полученной в результате преобразования функции и часто может быть крайне невразумительным.
— просто признайтесь, что вам плагин просто не понравился. пора бы открыть глаза, на дворе 21 век.
Это не означает что все велосипедисты должны пересесть на газонокосилки
Статья интересная, технология интересная, я хотел сказать только то что это узкоспециализированное направление, и применять бездумно налево и на право не стоит.
«Это вы ответите тогда когда вам скажут через 2 часа все должно быть готово»
подобные предположения вообще не имеют смысла, потому что если в 2012… в работе у вас все время так? рубите-рубите своим незаточенным топором…
«используя разные шаблонизаторы»
можно вообще не использовать новые технологии. а смысл вообще аякс использовать? иногда так проще получить какие-то данные. но иногда если есть зависимости, то приходится писать больше кода.
«сообщение об ошибке будет относиться к тексту полученной в результате преобразования функции»
а в других шаблонизаторах не так? сраный смарти например.
«Это не означает что все велосипедисты должны пересесть на газонокосилки»
никто и не заставляет. ваши выводы — не верны
«это узкоспециализированное направление, и применять бездумно налево и на право не стоит.»
это очевидно =)
подобные предположения вообще не имеют смысла, потому что если в 2012… в работе у вас все время так? рубите-рубите своим незаточенным топором…
«используя разные шаблонизаторы»
можно вообще не использовать новые технологии. а смысл вообще аякс использовать? иногда так проще получить какие-то данные. но иногда если есть зависимости, то приходится писать больше кода.
«сообщение об ошибке будет относиться к тексту полученной в результате преобразования функции»
а в других шаблонизаторах не так? сраный смарти например.
«Это не означает что все велосипедисты должны пересесть на газонокосилки»
никто и не заставляет. ваши выводы — не верны
«это узкоспециализированное направление, и применять бездумно налево и на право не стоит.»
это очевидно =)
Отлично подойдет для неиндексируемого контента типа бекэндов! Спасибо за обзор.
Что мешает иметь статику для роботов и недобраузеров, а для людей перехватывать события (клики и тп), подгружать только данные и отрисовывать их темплейтами?
Вроде ж, стандартная схема.
Вроде ж, стандартная схема.
Двойная работа?..
Во-первых, это практично. Упрощаем жизнь хорошим пользователям с правильными браузерами/опциями и уменьшаем нагрузку на сервер.
Во-вторых, если считать грубо, то работа не двойная, а много меньшая, так как у нас уже готова модель (при правильной организации приложения), уже есть статический вью, и контроллер для их связки. Осталось сделать, грубо говоря, еще один вью (jquery templates) и немного подтюнить контроллер для анализа типа запроса (ajax/не ajax). Так что процентов до 30 перетрудимся (но точно не еще на 100).
Во-вторых, если считать грубо, то работа не двойная, а много меньшая, так как у нас уже готова модель (при правильной организации приложения), уже есть статический вью, и контроллер для их связки. Осталось сделать, грубо говоря, еще один вью (jquery templates) и немного подтюнить контроллер для анализа типа запроса (ajax/не ajax). Так что процентов до 30 перетрудимся (но точно не еще на 100).
Идеально было бы иметь такой же парсер темплейтов на сервере.
Если это Microsoft сделал, то может уже такой на .net, может кто знает?
Если это Microsoft сделал, то может уже такой на .net, может кто знает?
Вообще я имею ввиду под «таким же парсером» — с таким же синтаксисом шаблона.
Чтобы html-темплейт и входные данные не переписывать, а использовать одни и те же на серверной и клиентской части.
Чтобы html-темплейт и входные данные не переписывать, а использовать одни и те же на серверной и клиентской части.
Хм… Принципиально это осуществимо, но на практике на стороне сервера или будет масса ограничений, или все будет работать невыносимо медленно.
Что значит невыносимо медленно. Медленнее, чем парсинг .aspx страниц?
Ну да, они компилируются, но ведь и темплейты компилируются, даже клиентские.
А что Razor? У него какая-то особая обработка? Почему остальные должны работать невыносимо медленнее?
Ну да, они компилируются, но ведь и темплейты компилируются, даже клиентские.
А что Razor? У него какая-то особая обработка? Почему остальные должны работать невыносимо медленнее?
Вы забыли, что в jQuery Templates вы можете в том числе работать с DOM страницы, а для сервера разбирать каждую отдаваемую им страницу будет очень накладно.
Ну а если от этого отказаться, то все вполне осуществимо, можно даже попробовать обойтись без JS на стороне сервера ;-)
Script#: C# to Javascript Converter
michaelsync.net/2007/10/29/script-c-to-javascript-converter
Что же касается Web Forms и Razor, то они после разбора и компиляции кэшируются. Кстати, в отличие от Razor ASPX даже не парсится, а просто разбивается на части по ключевым меткам (<@...> и <%...%>).
Ну а если от этого отказаться, то все вполне осуществимо, можно даже попробовать обойтись без JS на стороне сервера ;-)
Script#: C# to Javascript Converter
michaelsync.net/2007/10/29/script-c-to-javascript-converter
Что же касается Web Forms и Razor, то они после разбора и компиляции кэшируются. Кстати, в отличие от Razor ASPX даже не парсится, а просто разбивается на части по ключевым меткам (<@...> и <%...%>).
Вы наверное, не очень понимаете зачем мне этот парсер.
Если почитать текущую ветку, то становится понятно, что нужен механизм создания страницы для роботов и юзеров без JS.
Чтобы сформированный HTML сразу передался на клиента. Тут не нужны никакие DOM и обновление при изменении данных и прочие плюшки.
Если почитать текущую ветку, то становится понятно, что нужен механизм создания страницы для роботов и юзеров без JS.
Чтобы сформированный HTML сразу передался на клиента. Тут не нужны никакие DOM и обновление при изменении данных и прочие плюшки.
отличная статья, пожалуй, самая полная, если не единственная, на русском по теме
вас в гугле штоли забанили? чем вы, хомячки хабра, лучше хомячков из контакта, если у вам интернет заканчивается на хабре?
www.linkexchanger.su/2010/644.html
www.linkexchanger.su/2010/644.html
Уже применил в генераторе смет моей студии разработки сайтов.
раньше использовал sprintf
Спасибо, обязательно попробую на одном из своих проектов.
Огромное спасибо за статью! Уже успели обсудить с коллегами, сегодня пробуем внедрять.
UFO just landed and posted this here
В избранное!
Коллеги, объясните мне пожалуйста практическую ценность данной статьи? Чем она отличается от официально документации и от статей на русском, которые были написаны несколько месяцев назад? Если вы собираетесь это использовать то проще же просто поискать в гугле. А если не собираетесь, то зачем вам сейчас эта информация? Почему вы считаете этот информационный мусор полезным? Конечно, я уже задавал этот вопрос в других подобных статьях, что отразилось сами знаете на чем, но я до сих пор не понимаю как можно быть довольным отрывочными сведениями? Ведь статья в любом случае хуже документации охватывает объем возможностей предмета обзора. Иногда, конечно, статьи помогают разобраться и начать использовать что-то сложное, но в данном случае плагин настолько прост, что рассказывать не о чем.
У меня есть несколько знакомых, которые тоже занимаются «сайтостроительством», только их знания ограничены подобными статьями, и они меня постоянно задалбывают тупейшими вопросами, а причина — одна: они не читают книг, где описаны все основы. А заказчики потом получают говносайты с проваленными сроками. Давайте мы все таки будем стараться быть профессионалами, и будем читать книги. А статьи будем требовать только на те темы, которые не освещены в других местах, которые содержат уникальные исследования авторов.
А если у этой статьи основная цель — рассказать о том, что такой плагин есть, то достаточно воспользоваться поиском, об этом новость уже была.
У меня и без этой статьи почему-то не было сложностей с использованием этого плагина в одном из приложений для Моего Мира. Данные я получаю в json, и генерирую представление уже загруженными шаблонами. Визуально работает очень быстро.
У меня есть несколько знакомых, которые тоже занимаются «сайтостроительством», только их знания ограничены подобными статьями, и они меня постоянно задалбывают тупейшими вопросами, а причина — одна: они не читают книг, где описаны все основы. А заказчики потом получают говносайты с проваленными сроками. Давайте мы все таки будем стараться быть профессионалами, и будем читать книги. А статьи будем требовать только на те темы, которые не освещены в других местах, которые содержат уникальные исследования авторов.
А если у этой статьи основная цель — рассказать о том, что такой плагин есть, то достаточно воспользоваться поиском, об этом новость уже была.
У меня и без этой статьи почему-то не было сложностей с использованием этого плагина в одном из приложений для Моего Мира. Данные я получаю в json, и генерирую представление уже загруженными шаблонами. Визуально работает очень быстро.
объясните мне пожалуйста практическую ценность вашего комментария?
я взываю к разуму хомячков, чтобы в интернете было меньше бесполезной информации.
все мы не любим, когда в поисковой выдаче мы получаем кучу сеошного мусора, который генерируют ради увеличения посещаемости и может быть продаж с сайта. а в данном случае цель — увеличение сами-знаете-чего.
все мы не любим, когда в поисковой выдаче мы получаем кучу сеошного мусора, который генерируют ради увеличения посещаемости и может быть продаж с сайта. а в данном случае цель — увеличение сами-знаете-чего.
это крайне полезная статья, а бесполезное тут — только ваш собственный комментарий.
воспользуйтесь своим собственным советом и перестаньте засорять интернеты
воспользуйтесь своим собственным советом и перестаньте засорять интернеты
ты не прав. эта статья — лишь повторение того, что уже было где-то написано. но хомячки такие хомячки и их тысячи…
Да, тема уже освещалась, даже выше была дана ссылка на линкэксчейнджер, но там слишком сухо все дано, да и приравнивать подобные статьи к SEO-мусору совсем неправильно. Статья как основа для ознакомления с плагином очень даже хороша: дана вся информация, видны авторские исследования и советы по использованию. Получилось довольно полно, к тому ж автор честно дал ссылки на другие источники для более глубоко погружения в тему.
Есть тесты производительности? И если можно, где в реальных проектах это может быть удобным? Мне видится удобным для каких-то небольших списков данных, как в приведенном примере, а в качестве модели для построения всего сайта может быть громоздко.
Производительность можно оценить, прочитав вот эту статью (ссылка на нее есть в конце статьи):
www.viget.com/extend/benchmarking-javascript-templating-libraries/
Правда, в ней речь идет других jQuery Templates… :) Но тестовый код доступен на GitHub, и вы можете добавить туда свой тест — и если вы это сделаете, я буду вам очень признателен. Я же постараюсь в ближайшие дни найти время и протестировать производительность jQuery Templates + последние версии других template engines.
На мой взгляд производительность jQuery Templates «достаточна для любых практических целей», IMHO тут важно соблюсти баланс (ну, например, использовать {{each}} для вывода массива строк через запятую не лучший вариант, метод join() справится с этим лучше — но зато это хороший демонстрационный пример).
В реальных проектах я использую jQuery Templates для показа различных списков, для кастомизации диалогов, использовал его также в достаточно нетривиальном редакторе workflow – и сэкономил при этом много времени. Каких-то проблем с громоздкостью я не заметил, но это индивидуальное восприятие.
Использовать jQuery Templates в своих проектах или нет решать вам, исходя из ваших индивидуальных предпочтений и требований к вашим проектам. Основную причину, по которой я выбор именно jQuery я уже озвучил – я не большой любитель решать проблемы в чужом коде, а этому плагину гарантирована поддержка как части проекта jQuery.
www.viget.com/extend/benchmarking-javascript-templating-libraries/
Правда, в ней речь идет других jQuery Templates… :) Но тестовый код доступен на GitHub, и вы можете добавить туда свой тест — и если вы это сделаете, я буду вам очень признателен. Я же постараюсь в ближайшие дни найти время и протестировать производительность jQuery Templates + последние версии других template engines.
На мой взгляд производительность jQuery Templates «достаточна для любых практических целей», IMHO тут важно соблюсти баланс (ну, например, использовать {{each}} для вывода массива строк через запятую не лучший вариант, метод join() справится с этим лучше — но зато это хороший демонстрационный пример).
В реальных проектах я использую jQuery Templates для показа различных списков, для кастомизации диалогов, использовал его также в достаточно нетривиальном редакторе workflow – и сэкономил при этом много времени. Каких-то проблем с громоздкостью я не заметил, но это индивидуальное восприятие.
Использовать jQuery Templates в своих проектах или нет решать вам, исходя из ваших индивидуальных предпочтений и требований к вашим проектам. Основную причину, по которой я выбор именно jQuery я уже озвучил – я не большой любитель решать проблемы в чужом коде, а этому плагину гарантирована поддержка как части проекта jQuery.
Производительность не очень: habrahabr.ru/blogs/jquery/108067/
Продолжая идею, переносим на js контроллер и модели, и посылаем только запросы к бд и системе.
А шаблоны можно как-то закэшировать на клиенте? Что-то типа
Парсер скушал
<script type="text/x-jquery-tmpl" src="template.html"></script>Так – нет, вы не сможете получить доступ к тексту шаблона. Но при динамической загрузке шаблоны будут кэшироваться by default.
Сейчас проверил — браузер не загружает автоматически script src с неизвестным mime.
Как вариант, модифицировать либу и делать XMLHTTPRequest запросы на src таких элементов. Либо на ONDOMLOADED повесить коллбэк, который загрузит все скрипты с MIME == text/x-jquery-tmpl в какой-то список и работать уже оттуда с ними.
Как считаете, хорошая идея?
Как вариант, модифицировать либу и делать XMLHTTPRequest запросы на src таких элементов. Либо на ONDOMLOADED повесить коллбэк, который загрузит все скрипты с MIME == text/x-jquery-tmpl в какой-то список и работать уже оттуда с ними.
Как считаете, хорошая идея?
1) По крайней мере IE запрашивает соответствующий файл с сервера, но доступ к его содержимому все равно не дает.
2) Загрузка шаблонов через AJAX — это не секрет:
$.get('Templates/DynamicLoading.htm', {}, function (templateBody) {
$.tmpl(templateBody, dataItems).appendTo('#movieListBag');
});
Если хотите задавать URLs таких шаблонов в теге SCRIPT — я не возражаю… ;-)
2) Загрузка шаблонов через AJAX — это не секрет:
$.get('Templates/DynamicLoading.htm', {}, function (templateBody) {
$.tmpl(templateBody, dataItems).appendTo('#movieListBag');
});
Если хотите задавать URLs таких шаблонов в теге SCRIPT — я не возражаю… ;-)
Не верю своим глазам: веб-программист, работающий в IE :)
Внимание, господа!
В статье Сергей отметил, что использование <script type=«xxxx»> предпочтительней, чем div. Хотел бы добавить, что, например, вот это:
Будет работать неверно. Будет выведен лишь первый список (ul). Выпадающий список и таблица окажутся пустыми. Причина столь странного поведения (из-за чего я некогда бросил jQuery template, т.к. проект уже поджимал) заключается в том, что по факту, движок возьмет $("#tpl")[0].innerHTML . При парсинге браузером удалятся все неправильные элементы: внутри table — все, кроме tr, внутри ul — все, кроме li. В результате, innerHTML выдаст:
небольшая поправочка: FF «вытолкнул» побочные элементы из тела таблицы наверх, из-за этого, движок выкинет невразумительную ошибку о том, что $index не существует. Как результат, получаем совершенно невменяемые вещи.
Использование
В статье Сергей отметил, что использование <script type=«xxxx»> предпочтительней, чем div. Хотел бы добавить, что, например, вот это:
<div id="tpl" style="display:none">
<ul>
{{each users}}
<li>${$index + 1}. ${$value}</li>
{{/each}}
</ul>
<select>
{{each users}}
<option value="${$index + 1}">${$index + 1} . ${$value}</option>
{{/each}}
</select>
<table>
{{each(ind, value) users}}
<tr>
<td>${ind + 1}</td>
<td>${value}</td>
</tr>
{{/each}}
</table>
</div>
Будет работать неверно. Будет выведен лишь первый список (ul). Выпадающий список и таблица окажутся пустыми. Причина столь странного поведения (из-за чего я некогда бросил jQuery template, т.к. проект уже поджимал) заключается в том, что по факту, движок возьмет $("#tpl")[0].innerHTML . При парсинге браузером удалятся все неправильные элементы: внутри table — все, кроме tr, внутри ul — все, кроме li. В результате, innerHTML выдаст:
<ul>
{{each users}}
<li>
${$index + 1}. ${$value}
</li>
{{/each}}
</ul>
<select>
<option value="${$index + 1}">${$index + 1} . ${$value}</option>
</select>
{{each(ind, value) users}} {{/each}}
<table>
<tbody>
<tr>
<td>
${ind + 1}
</td>
<td>
${value}
</td>
</tr>
</tbody>
</table>
небольшая поправочка: FF «вытолкнул» побочные элементы из тела таблицы наверх, из-за этого, движок выкинет невразумительную ошибку о том, что $index не существует. Как результат, получаем совершенно невменяемые вещи.
Использование
… <script> решает проблему.
Кстати, нафига они делают $("#tpl")[0] немного неясно… если элемент не найден, шаблон вываливается с ошибкой… имхо, правильнее было бы проверку делать или уж как все jQuery плагины, обрабатывать и возвращать нодлист.
Кстати, нафига они делают $("#tpl")[0] немного неясно… если элемент не найден, шаблон вываливается с ошибкой… имхо, правильнее было бы проверку делать или уж как все jQuery плагины, обрабатывать и возвращать нодлист.
Хорошее уточнение, с вашего разрешения добавлю его в текст :)
Добавил в текст ваш пример + пример динамической загрузки связанных шаблонов на основе вашей библиотеки WaitSync.
е-мое… опять опечатался… внутри select — все, кроме option.
Да это же рай для всяких контент-грабберов :)
Только если вы хотите грабить свой контент, контент чужого сайта вам никто не отдаст :)
Ну как это не отдадите. А это:
var dataItems = [
{
title: 'Бандиты',
thumbnail: 'Bandits.jpg',
director: 'Барри Левинсон',
actors: ['Брюс Уиллис', 'Билли Боб Торнтон', 'Кейт Бланшетт'],
year: 2001,
budget: 95000000,
grossRevenue: 67631903,
rating: 0,
frames: ['Bandits-1.jpg', 'Bandits-2.jpg', 'Bandits-3.jpg', 'Bandits-4.jpg', 'Bandits-5.jpg']
},
Sign up to leave a comment.
Работаем с jQuery Templates