Pull to refresh

Comments 32

интересно, а если будет много шаблонов, какова будет скорость выполнения?
если честно, скорость я не проверял, но этот метод не претендует бить скоростные характеристики, он просто освобождает от кода который Вы писали бы для этих «много шаблонов» в реализации DOM, потому как если делать все это через DOM, то размер кода был бы гораздо больше

зы: насчет скорости… меня конечно смущают регулярные выражения, но так же я знаю что создание обьекта тоже задача не из легких, возможно я сегодня поэксперементирую с десятком вложенных дивов и опишу результаты по скорости
Пару замечаний, если позволите:
1. Подобная функциональность элементарно реализуется без всяких классов, т.е чтобы класс имел право на существование нужно расширить функциональность.
2. Для каждого нового темплейта создаться куча лишних функций(точнее 1 функция evaluate), надо переписать класс так, чтобы использовать прототип, да и вообще функция evaluate(и название лучше заменить на eval =) ) сделана не очень хорошо. Или вообще убрать класс и сделать функцию =)
3(знаю соврал). Ну что за скобки "#{", "}" почему они разные? Неудобно ведь =)
4. В framework'ах есть подобная функциональность.

Я не придираюсь, просто решил оставить мнение, насколько оно обосновано судить вам =)
1 — это реализовано в классе а не в функции итд для того чтобы один парсер соответствовал одному темплейту, расширить функциональность ничего не мешает никому, берете и расширяете :)
2 — для нового темплейта создается не одна функция а один класс, класс можно дополнить методами, название функции «evaluate» оставил как была изначально (я выковырял этот парсер из фреймворка)
3 — скобки оставил как были изначально (меняется регулярное выражение, меняются скобки)
4 — подобная функциональность была только в одном фреймворке, именно из него я и вытянул эту штуку, потому как им не пользуюсь а фича понадобилась

а чем функция evaluate сделана не очень хорошо? помоему преллестно, свои задачи выполняет замечательно, проста
1. Ну дык раз уж создавать, а тем более потом выкладывать в общее пользование класс, то стоит сделать его более функциональным. Я рассматриваю класс в том виде, в котором он выложен вами, тут нужно сильно много расширять =).
3. Да, признаю, это легко поменять.
4. Ясно.

Функция evaluate сделана плохо тем, что ее можно написать гораздо удобней для чтения. Помещать «смысл» функции целиком в return, через метод встроенного класс, где используется еще 1 анонимная функция… ну не знаю, мне это кажется несколько странным.
>… Помещать «смысл» функции целиком в return… кажется несколько странным.

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

this.evaluate = function(object)
{
return _template.replace(/(#\{.*?\})/g, function(match)
{
var key = match.substring(2, match.length-1);
return (undefined !== object[key] )? object[key]: "";
})
}
UFO just landed and posted this here
если честно не понял к чему это =) у меня 2 варианта:
1 — JS не дорос до темплейтов
2 — код — отстой
UFO just landed and posted this here
хорошо, раз так, а как Вы вставляете данные имеющую сложную структуру в html после приема данных с сервера с помошью ajax?
UFO just landed and posted this here
при передаче данных в виде форматированного html идет бОльшая нагрузка на сервер при формировании оного, потом скорость передачи данных, а клиентские машины в наше время довольно таки мошьные =) можно перекинуть часть нагрузки на них :) а вообще я этим способом формирую урлы для отправки
UFO just landed and posted this here
=) ну Вы плохо читали, вообще то этот код я выковырял из одного из «распространенных» фреймворков под названием prototype, когда я им пользовался мне понравилась эта фича, вот теперь я его не использую, а фича понадобилась… вот так вот
UFO just landed and posted this here
«наверное оно бы вошло в состав распространенных фреймворков типа jquery или prototype.»
www.prototypejs.org/api/template, кстати, не отсюда ли автор взял код?
цитирую себя же: «но разработчики prototype сделали более удачную реализацию… собственно именно у них я и позаимствовал идею, немного упростив ее»
кстати если немножечко изменить этот код, то он будет работать быстрей чем при создании элементов с помошью DOM почти в 2 раза
Будьте добры, добавьте эти изменения в пост
Здесь не хватает вот этой ссылки

ejohn.org/blog/javascript-micro-templating
у Вашего алгоритма не совсем такая схема обработки, принцип ведь работы всех шаблонизаторов похожий: вставить в темплейт болванки и заменить их на данные, а ссылка на оригинальный исходник вот: www.prototypejs.org/api/template
… Некоторые передают ajax-ом сразу html код и вставляют его в нужное место, но разработчики prototype сделали более удачную реализацию...
очень не удачно сформулировали предложение, нужно добавить слова «мое мнение» или привести доказательства чем одно лучше (хуже) другого. а то народ в заблуждение вводите. вставка html кода имеет свои приимущества. такой подход даже имееет отдельное название AHAH, к примеру одно из таких приимуществ — легко можно реализовть нормальную индексацию сайта при использовании AJAX. я скажу даже больше — можно улучшить индексацию используя AHAH.
насчет индексации, мое мнение, на сколько мне известно поисковики не выполняют скрипты и поэтому им не видим контент переданный с помошью AHAH… но я не уверен

если бы Вы внимательно почитали что я пишу, и посмотрели бы исходники и примеры, то Вы бы заметили что я тоже вставляю HTML и ни что иное, а лучше метод тем что не засоряется канал не нужным мусором из HTML тегов постоянно, а только один раз при загрузке страницы + можно использовать мошь клиентских машин (которые в наше время неплохи) для разгрузки сервера от, опять же, лишних телодвижений (пусть они и маленькие, но когда их много и они напрягают)
В своих проектах я сам использую JS Template. Но если вы будете везде применять JSON, особенно для генерации контента — то вам придется либо делать отдельный интерфейс для поисковиков, либо забыть про нормальную индексацию вашего сайта. JSON для генерации контента имеет смысл применять в случае когда индексация не важна, либо для обмена служебными сообщениями между клиентом и сервером.

Поисковики не выполняют скрипты и им не виден контент передаваемый с помощью AHAH, зато при грамотном построении поисковики ходят по обычным ссылкам и видят только ту часть контента, которая относится к конкретной ссылке в нормальном размеченном тегами виде. таким образом вы можете совмещать приятное с полезным: динамически подгружать контент и оставить о себе след в поисковиках, при этом не делая дополнительных телодвижений.
=) что мешает построить грамотную ссылку при использовании AJAX (принимая JSON)? я думаю ничего… так что с точки зрения индексации неважно что использую AHAH, AJAX и др. главное правильная организация ссылок для поисковиков, так что мой способ не хуже AHAH а лучше экономикой трафика и снижением действий сервера
наверно вам ничего не мешает построить нормальную ссылку для поисковика при использовании JSON. лично мне мешает дополнительная работа, помоему вы называли это лишние телодвижения.

почитайте вот люди пишут itlife.habrahabr.ru/blog/44242/,
1) закумаритесь вы генерировать отдельно JSON отдельно HTML при таком подходе
2) я не говорил что ваш способ хуже, меня зацепило то что вы сказали что ваш способ лучше, причем не уточнили в каком случае. вообщем надо правильно строить не только сайты но и предложения. :)
не спорю, я не мастер русского языка, но насчет лишних телодвижений:
вы всеравно будете резать HTML вот и отделить кусочек от него ничего сложного нет, потом этот кусочек в цикле парсится и в итоге получается блок любой длины, вплоть до сложных таблиц, при передаче AHAH на загруженных серверах они будут засорять канал HTML тэгами, а мой подход (вернее создателей prototype) избавляет канал от этого мусора передавая только необходимые данные… причем JSON всегда (именно всегда) в одном формате, на сервере любой обьект/массив превращается в JSON одной строкой
буду резать HTML?
в грамотно реализованных системах процесс обычно происходит так: данные лежат на сервере в виде обьектов — при запросе данные извлекаются и из них формируется контент (HTML, XML, JSON, другое)

теперь давайте просчитаем телодвижения
HTML:
1) если зашел робот или без чел. AJAX -> извлечь данные — сформировать HTML — отдать на клиент
2) если зашел человек с AJAX -> извлечь данные — сформировать HTML — отдать на клиент — отренедерить innerHTML

JSON:
1) если зашел робот или без чел. AJAX -> извлечь данные — сформировать HTML — отдать на клиент
2) если зашел человек с AJAX -> извлечь данные — сформировать JSON — отдать на клиент — разпарсить — отрендерить

разницу чувствуете? в случае с HTML второе это продолжение первого, в случае с JSON — две разные процедуры со всеми вытекающими
Вам жалко 50 миллисекунд клиентского времени? причем я _очень_ увеличил время
довольно большой кусок не очень сложной структуры рендерился за 7 миллисекунд
если учесть что у некоторых слабые каналы(у меня например на хабре каменты через раз проходят, пост вообще с трудом могу написать) то Ваш код будет ходить намного медленней чем 7 мсек. поскольку напичкан HTML =) не знаю как Вам, а мне, как клиенту со слабым каналом более подходит мой вариант
все понятно, мы с вами говорим на разных языках, видать этого от того что у нас разный опыт.

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

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

Вывод: вы можете передавать данные и двоичном виде, это ваше личное дело. Только в следующий раз при написании умозаключений сравнительного анализа приводите хоть какие-то доводы ваших утверждений.
только что посмотрел что пишут люди, посмотрел сайты… я никогда не буду делать сайты с избыточность в 200%, темплейты которые загружают по 2 языка «на всякий случай» это помоему не лучший вариант написания, а вдруг я не хочу английский? но нет, программист лучше меня знает что мне надо и с каждым запросом мне будет приходит 2 контента… а если языков будет 7? аяксовый сайт без кэша себя почти не окупает, зачем мне по сто раз загружать неизменный контент? не надо мне давать в пример неудачные реализации
кстати я использую пхп, у него есть встроенная функция для конвертации в JSON это добавляет скорости
Sign up to leave a comment.

Articles