@psg123431 янв 2011 в 03:58

Работаем с jQuery Templates

20 мин

141K

jQuery *

+192

Комментарии 67

@sergeyzwezdin 31 янв 2011 в 04:08

Содержательно. Спасибо.

@Toy 31 янв 2011 в 04:15

Отличная либа! Уже предвижу, в каких проектах и где ее можно применить

@taliban 31 янв 2011 в 13:16

О, предвидцы на хабре! Подскажите пожалуйста мне где можно эту либу использовать, в каких проектах?

@Toy 31 янв 2011 в 13:18

в персональных, а вы с какой целью интересуетесь?

@taliban 31 янв 2011 в 13:26

Омг, извините, не знал что чувство юмора это так сложно

@TheShock 31 янв 2011 в 17:04

Не обижайтесь, но в этот раз шутка так себе =)

@Nc_Soft 31 янв 2011 в 04:34

Удобно, но сеошники это не одобрят…

@psg1234 31 янв 2011 в 04:45

Не SEO единым… Есть еще и бизнес web apps.

@Bygaga 31 янв 2011 в 12:04

А зачем это в бизнес web-apps? такие системы не являются настолько нагруженными что бы оптимизировать их выносом обработки фронтента на компьютер пользователя. Написание бекенда и фронтенда на разных системах шаблонизации такой же бред, усложняющий поддержку.
То есть остаются исключительно специфические web системы, которые опять же не настолько нагружены что бы тратить время программистов на отлавливание багов в шаблонах созданных таким способом.

Итог:
+ перенос нагрузки по формированию шаблона на сторону пользователя
— дополнительные навыки верстальщика и программиста
— сеошники это точно не одобрят
— дополнительные затраты времени отлавливание ошибок

@msfs11 31 янв 2011 в 16:56

— дополнительные навыки верстальщика и программиста
4 часа на чтение и усвоение 6 листов документации
— сеошники это точно не одобрят
никто не обязывает, что вообще за глупость такая — использовать это публичной части. что надо курить, чтобы додуматься до этого?..
— дополнительные затраты времени отлавливание ошибок
что за глупость? чем отличается время поиска ошибок с использованием одного или другого шаблонизатора. здесь же нет сложной логики, просто вывод переменных. если ошибся с названием переменной, то в консоль выведется ошибка, что такой переменной нет, остается только найти ее с помощью ctrl+f. так же, если понимать во что компилируется этот шаблон, то есть возможность использовать и вывод в консоль, и трассировку и прочее.

просто признайтесь, что вам плагин просто не понравился. пора бы открыть глаза, на дворе 21 век.

@Bygaga 31 янв 2011 в 19:27

— 4 часа на чтение и усвоение 6 листов документации
Это вы ответите тогда когда вам скажут через 2 часа все должно быть готово, какой смысл тратить это время, если этого можно не делать, да и потом еще получить проблемы с совместимостью.

— никто не обязывает, что вообще за глупость такая — использовать это публичной части. что надо курить, чтобы додуматься до этого?..
Покажите мне смысл писать для фронтенда и бекенда используя разные шаблонизаторы? меня вполне устраивает ajax подгрузка на бекенде.

— что за глупость? чем отличается время поиска ошибок с использованием одного или другого шаблонизатора…
Цитата с текста статьи: Дело в том, что jQuery Templates выполняет относительно простое преобразование текста шаблона, поэтому если вы допустите ошибку в выражении, то сообщение об ошибке будет относиться к тексту полученной в результате преобразования функции и часто может быть крайне невразумительным.

— просто признайтесь, что вам плагин просто не понравился. пора бы открыть глаза, на дворе 21 век.
Это не означает что все велосипедисты должны пересесть на газонокосилки

Статья интересная, технология интересная, я хотел сказать только то что это узкоспециализированное направление, и применять бездумно налево и на право не стоит.

@msfs11 31 янв 2011 в 19:51

«Это вы ответите тогда когда вам скажут через 2 часа все должно быть готово»
подобные предположения вообще не имеют смысла, потому что если в 2012… в работе у вас все время так? рубите-рубите своим незаточенным топором…

«используя разные шаблонизаторы»
можно вообще не использовать новые технологии. а смысл вообще аякс использовать? иногда так проще получить какие-то данные. но иногда если есть зависимости, то приходится писать больше кода.

«сообщение об ошибке будет относиться к тексту полученной в результате преобразования функции»
а в других шаблонизаторах не так? сраный смарти например.

«Это не означает что все велосипедисты должны пересесть на газонокосилки»
никто и не заставляет. ваши выводы — не верны

«это узкоспециализированное направление, и применять бездумно налево и на право не стоит.»
это очевидно =)

@topy 31 янв 2011 в 06:22

Отлично подойдет для неиндексируемого контента типа бекэндов! Спасибо за обзор.

@davv 31 янв 2011 в 07:17

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

@aavezel 31 янв 2011 в 07:27

Двойная работа?..

@davv 31 янв 2011 в 07:40

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

Во-вторых, если считать грубо, то работа не двойная, а много меньшая, так как у нас уже готова модель (при правильной организации приложения), уже есть статический вью, и контроллер для их связки. Осталось сделать, грубо говоря, еще один вью (jquery templates) и немного подтюнить контроллер для анализа типа запроса (ajax/не ajax). Так что процентов до 30 перетрудимся (но точно не еще на 100).

@webdew 31 янв 2011 в 08:46

Идеально было бы иметь такой же парсер темплейтов на сервере.
Если это Microsoft сделал, то может уже такой на .net, может кто знает?

@psg1234 31 янв 2011 в 08:50

Razor! ;-)

habrahabr.ru/blogs/net/111837/
razorengine.codeplex.com/

@webdew 31 янв 2011 в 09:05

Вообще я имею ввиду под «таким же парсером» — с таким же синтаксисом шаблона.

Чтобы html-темплейт и входные данные не переписывать, а использовать одни и те же на серверной и клиентской части.

@psg1234 31 янв 2011 в 09:14

Хм… Принципиально это осуществимо, но на практике на стороне сервера или будет масса ограничений, или все будет работать невыносимо медленно.

@webdew 31 янв 2011 в 09:22

Что значит невыносимо медленно. Медленнее, чем парсинг .aspx страниц?
Ну да, они компилируются, но ведь и темплейты компилируются, даже клиентские.

А что Razor? У него какая-то особая обработка? Почему остальные должны работать невыносимо медленнее?

@psg1234 31 янв 2011 в 09:39

Вы забыли, что в jQuery Templates вы можете в том числе работать с DOM страницы, а для сервера разбирать каждую отдаваемую им страницу будет очень накладно.

Ну а если от этого отказаться, то все вполне осуществимо, можно даже попробовать обойтись без JS на стороне сервера ;-)

Script#: C# to Javascript Converter
michaelsync.net/2007/10/29/script-c-to-javascript-converter

Что же касается Web Forms и Razor, то они после разбора и компиляции кэшируются. Кстати, в отличие от Razor ASPX даже не парсится, а просто разбивается на части по ключевым меткам (<@...> и <%...%>).

@webdew 31 янв 2011 в 09:58

Вы наверное, не очень понимаете зачем мне этот парсер.
Если почитать текущую ветку, то становится понятно, что нужен механизм создания страницы для роботов и юзеров без JS.

Чтобы сформированный HTML сразу передался на клиента. Тут не нужны никакие DOM и обновление при изменении данных и прочие плюшки.

@psg1234 31 янв 2011 в 10:51

Зря вы так, я все прекрасно понимаю, поэтому и сказал о куче ограничений :)

@XaocCPS 31 янв 2011 в 05:06

отличная статья, пожалуй, самая полная, если не единственная, на русском по теме

@msfs11 31 янв 2011 в 10:17

вас в гугле штоли забанили? чем вы, хомячки хабра, лучше хомячков из контакта, если у вам интернет заканчивается на хабре?
www.linkexchanger.su/2010/644.html

@benone 1 фев 2011 в 16:21

А если колонку сделать в 150 пикселей, указанная статья будет почти бесконечная)

@Aler 31 янв 2011 в 05:46

Уже применил в генераторе смет моей студии разработки сайтов.

@Aler 31 янв 2011 в 05:47

раньше использовал sprintf

@FrISer 31 янв 2011 в 05:50

Спасибо, обязательно попробую на одном из своих проектов.

@iAlukard 31 янв 2011 в 06:39

Огромное спасибо за статью! Уже успели обсудить с коллегами, сегодня пробуем внедрять.

НЛО прилетело и опубликовало эту надпись здесь

@mace 31 янв 2011 в 07:34

В избранное!

@msfs11 31 янв 2011 в 07:39

Коллеги, объясните мне пожалуйста практическую ценность данной статьи? Чем она отличается от официально документации и от статей на русском, которые были написаны несколько месяцев назад? Если вы собираетесь это использовать то проще же просто поискать в гугле. А если не собираетесь, то зачем вам сейчас эта информация? Почему вы считаете этот информационный мусор полезным? Конечно, я уже задавал этот вопрос в других подобных статьях, что отразилось сами знаете на чем, но я до сих пор не понимаю как можно быть довольным отрывочными сведениями? Ведь статья в любом случае хуже документации охватывает объем возможностей предмета обзора. Иногда, конечно, статьи помогают разобраться и начать использовать что-то сложное, но в данном случае плагин настолько прост, что рассказывать не о чем.
У меня есть несколько знакомых, которые тоже занимаются «сайтостроительством», только их знания ограничены подобными статьями, и они меня постоянно задалбывают тупейшими вопросами, а причина — одна: они не читают книг, где описаны все основы. А заказчики потом получают говносайты с проваленными сроками. Давайте мы все таки будем стараться быть профессионалами, и будем читать книги. А статьи будем требовать только на те темы, которые не освещены в других местах, которые содержат уникальные исследования авторов.
А если у этой статьи основная цель — рассказать о том, что такой плагин есть, то достаточно воспользоваться поиском, об этом новость уже была.
У меня и без этой статьи почему-то не было сложностей с использованием этого плагина в одном из приложений для Моего Мира. Данные я получаю в json, и генерирую представление уже загруженными шаблонами. Визуально работает очень быстро.

@XaocCPS 31 янв 2011 в 09:27

объясните мне пожалуйста практическую ценность вашего комментария?

@msfs11 31 янв 2011 в 09:53

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

@XaocCPS 31 янв 2011 в 09:56

это крайне полезная статья, а бесполезное тут — только ваш собственный комментарий.
воспользуйтесь своим собственным советом и перестаньте засорять интернеты

@msfs11 31 янв 2011 в 10:24

ты не прав. эта статья — лишь повторение того, что уже было где-то написано. но хомячки такие хомячки и их тысячи…

@pluseg 14 фев 2011 в 09:41

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

@msfs11 14 фев 2011 в 10:41

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

@valerad12 31 янв 2011 в 08:15

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

@psg1234 31 янв 2011 в 08:44

Производительность можно оценить, прочитав вот эту статью (ссылка на нее есть в конце статьи):

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.

@aavezel 31 янв 2011 в 12:28

Производительность не очень: habrahabr.ru/blogs/jquery/108067/

@Moric 31 янв 2011 в 08:46

Продолжая идею, переносим на js контроллер и модели, и посылаем только запросы к бд и системе.

@psg1234 31 янв 2011 в 08:55

Мне кажется, что это не очень хорошая идея ;-) А вот three-tier app вполне можно построить.

@b0n3Z 31 янв 2011 в 13:21

А шаблоны можно как-то закэшировать на клиенте? Что-то типа

@b0n3Z 31 янв 2011 в 13:22

Парсер скушал

<script type="text/x-jquery-tmpl" src="template.html"></script>

@psg1234 31 янв 2011 в 13:28

Так – нет, вы не сможете получить доступ к тексту шаблона. Но при динамической загрузке шаблоны будут кэшироваться by default.

@b0n3Z 31 янв 2011 в 13:45

Сейчас проверил — браузер не загружает автоматически script src с неизвестным mime.
Как вариант, модифицировать либу и делать XMLHTTPRequest запросы на src таких элементов. Либо на ONDOMLOADED повесить коллбэк, который загрузит все скрипты с MIME == text/x-jquery-tmpl в какой-то список и работать уже оттуда с ними.
Как считаете, хорошая идея?

@psg1234 31 янв 2011 в 13:53

1) По крайней мере IE запрашивает соответствующий файл с сервера, но доступ к его содержимому все равно не дает.

2) Загрузка шаблонов через AJAX — это не секрет:

$.get('Templates/DynamicLoading.htm', {}, function (templateBody) {
$.tmpl(templateBody, dataItems).appendTo('#movieListBag');
});

Если хотите задавать URLs таких шаблонов в теге SCRIPT — я не возражаю… ;-)

@o_O_Tync 31 янв 2011 в 16:00

Не верю своим глазам: веб-программист, работающий в IE :)

@psg1234 31 янв 2011 в 16:08

IMHO нужно использовать тот же софт, что и твои пользователи.

@o_O_Tync 31 янв 2011 в 17:26

Для тестирования — конечно, но для разработки есть инструменты и поудобнее :) Тоже IMHO, конечно :)

@MAXH0 31 янв 2011 в 17:30

Представил себе дизайнера ретуширующего фото в Пайнт.нете :-)))

@kirilloid 31 янв 2011 в 18:44

Бедный, но честный так и будет работать. Хотя не знаю, может, gimp покруче pdn будет.
А вот браузеры со всеми их плагинами для разработчиков все одинаково доступны.

@TEHEK 31 янв 2011 в 23:16

Внимание, господа!

В статье Сергей отметил, что использование <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 не существует. Как результат, получаем совершенно невменяемые вещи.

Использование

@TEHEK 31 янв 2011 в 23:41

… <script> решает проблему.

Кстати, нафига они делают $("#tpl")[0] немного неясно… если элемент не найден, шаблон вываливается с ошибкой… имхо, правильнее было бы проверку делать или уж как все jQuery плагины, обрабатывать и возвращать нодлист.

@psg1234 1 фев 2011 в 03:50

Думаю, что это просто баг :)

@psg1234 1 фев 2011 в 03:49

Хорошее уточнение, с вашего разрешения добавлю его в текст :)

@psg1234 1 фев 2011 в 06:20

Добавил в текст ваш пример + пример динамической загрузки связанных шаблонов на основе вашей библиотеки WaitSync.

@TEHEK 1 фев 2011 в 15:46

o_O приятно ошарашен =))))

@TEHEK 1 фев 2011 в 15:49

е-мое… опять опечатался… внутри select — все, кроме option.

@Shvonder 1 фев 2011 в 02:43

Да это же рай для всяких контент-грабберов :)

@psg1234 1 фев 2011 в 03:30

Только если вы хотите грабить свой контент, контент чужого сайта вам никто не отдаст :)

@Shvonder 1 фев 2011 в 05:06

Ну как это не отдадите. А это:

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']
    },

@psg1234 1 фев 2011 в 06:09

Ясно :) Ну, вы же понимаете, что все, что вы видите в браузере, может быть сграблено ;-)

@psg1234 1 фев 2011 в 06:18

Обновление:

1. Добавил пример побочных эффектов при размещении текста шаблона вне тега SCRIPT, способный вызвать серьезную головную боль (большое спасибо TEHEK за этот пример!).

2. Добавил пример динамической загрузки связанных шаблонов (опять спасибо TEHEK за полезную библиотеку :).

Зарегистрируйтесь на Хабре, чтобы оставить комментарий