А какие нужны? Работа на всех устройствах? Ну так и HTML4 прекрасно работает на многих устройствах. Зачем нам ещё какие-то HTML5 и плагины?
Плагины к браузеру сами по себе ущербны своей чужеродностью, небезопасностью
Что значит «чужеродность» и чем она ущербна? Дыры в безопасности могут быть и в браузере.
IE6 и IE7 — это старьё и занимает от силы треть. Силверлайта нет на гораздо большем числе машин.
Сильверлайт реализован в виде плагина, и его потому нетрудно скачать и установить, будучи даже полным профаном (в последнее время подобная операция делается в два клика). При этом пользователь кликнет куда надо, ибо у него будет красоваться сообщение c просьбой установить. Установка браузера для человека неискушённого — задача более нетривиальная.
HTML уже есть на телефонах и любых компьютерах в более-менее приличном виде.
А это «более-менее приличный вид» — это уровень цветных буковок. К тому времени, как в нём появится функционал, имеющийся в Silverlight, или хотя бы в JavaFX и Flash, может да, Silverlight успеет достаточно распространиться.
Мне кажется, это далеко не самая востребованная функция в «шаблонизаторах»
Тем не менее, когда всё-таки нужно что-то подобное, с XSLT приходится использовать костыли. Да и необходимость генерить XML, чтобы подать его на вход XSLT-шаблону несколько удручает. Ибо в случае даже с JAXB необходимо прописывать XML-схему и аннотации. Конечно, можно придумать свой костыль для простенького преобразования объектов в XML, но зачем, когда можно и без этого?
Вот странно, почему когда заходит речь об XSLT — в первую очередь начинают вспоминать Java и всё с ней связанное, будто это чуть ли не единственная среда, в которой можно им пользоваться.
Да нет, как раз более популярным в вебе является PHP, потому и про XSLT говорят, наверное, в контексте PHP. Так вот: в Java (Ruby, Python, C#) как раз с производительностью XSLT несколько лучше, ибо можно при старте сервера скомпилировать XSLT, а не парсить его каждый раз при HTTP-запросе. XSLT в Java и PHP теоретически может работать одинаково, т.к. скорее всего и там и там дёргается нативная реализация XSLT (хотя, возможно, в Java XSLT-процессор написан на Java, но от этого хуже не становится). Вот только если насчёт Java я уверен, что Java-код работает не медленее XSLT-процессора, то от PHP можно ждать чего угодно.
XSLT почти везде показывает себя лучше, чем традиционные костыли на интерпретируемых языках
А кто говорит про интерпретируемые? Я например, говорю больше про Java и .NET. Так вот там производительность шаблонизатора без XSLT должна быть выше, ибо в конечном итоге все сводится к нативным инструкция процессора, которые не работают с DOM-деревом в памяти, а сразу выводят текст. Ах да, им ещё не надо парсить входной XML.
Одна из немногих адекватных статей в пользу XSLT, на мой взгляд: blog.umi-cms.ru/sergej2/reabilitaciya_xmlxslt_tehnologij/
А ничего адекватного в статье нет. Только лозунги. И сравнение со Smarty в кривых руках. Ну например:
Правка XSLT шаблона не предполагает вмешательства в бизнес-логику и анализ структуры связей, которые могли бы использоваться в шаблоне будь он на Smarty.
Правда? Чего бы это вдруг шаблонизатор начал вмешиваться в бизнес-логику? А как XSLT от этого спасает? Во втором случае я вижу единственный вариант: в бизнес-логику лезет не сам шаблон, а некий слой, который вытаскивает данные и преобразует в XML. Для этого слоя даже есть название: presenter в паттерне MVP. Так вот если не устраивает MVC, то может стоит перейти на MVP? И в случае шаблонизатора без XSLT всё отличие presenter'а будет заключаться в том, что он просто вытащит данные, а не будет ещё преобразовывать их в XML.
Преимущества кратко озвучены. Подробнее см. на просторах интернета. А что значит «сильверлайта нет»? Сокеты нужны в RIA. Собтвенно, мне всегда казалось, что сильверлайт для них и предназначен. Или я ошибался?
Я тут как раз воюю с противниками «закрытых плагинов к браузеру». Ну для любителей открытых плагинов к браузеру есть Java Applets. А так, ну да, есть во флеше аналог web sockets, уже давно работающий на старых браузерах. Ну есть он и в сильверлайте. Только вот сильверлайт технически попродвинутее будет. А так да на безрыбье HTML5 и рак Flash — рыба.
На современных машинах? А ничего, что есть немалый такой контингент пользователей, юзающих IE6 и IE7, который хвалёный HTML5 не поддерживают? И они даже не могут посмотреть видео/послушать музыку без «закрытых плагинов для браузера». То же и с сокетами. Пока пошевелится w3c, пока разработчики наваяют/протестируют, пока все перейдут на IE9… Вот вам и прогресс, вот вам и развитие интернета.
Ну что же, у Silverlight очевидные преимущества перед HTML+CSS+JS. Это и производительность, и гораздо более мощный и выразительный язык, и, как следствие, лучшая поддержка со стороны IDE, и огромный функционал, доступный в .NET Framework. Например, видели WPF? Куда какому-нибудь Sencha до него по возможностям? Или ещё пример: 21 век на дворе, а W3C только начинает возиться с web sockets, когда в принципе и Java-апплеты, и Flash и Silverlight могут нормально общаться с сервером. Ну пройдёт ещё 10 лет и устареет последний браузер, не поддерживающий web sockets. А в «закрытых плагинах к браузеру» всё реализовано уже давно, но не кошерноЪ, как говорят мужики.
Не, ну никто конечно не мешает через какой-нибудь механизм привязки данных к XML вроде JAXB данные для XSLT подгонять. Но ради чего, если проще работать с шаблонизатором, который сразу данные в виде объектов принимает? Тем более, что есть ряд удобств в именно таком подходе. Что если, например, у нас есть строки в camelCase и нужно проставить подчёркивание между словами? В XSLT геморрой. В случае с объектами мы просто пишем метод, выполняющий соответствующее преобразование и дёргаем его из шаблона. Ну и моя личная практика показывает: XSLT тяжёлый. Вообще, я пришёл к убеждению, что не следует пихать XSLT во все дыры, как это делают некоторые. Ибо не только медленно, но и неудобно. Кстати, пример, когда XSLT мне показался ну очень неуместным (и жутко прожорливым) — Sandcastle
Интернет отпадает – это и медленно, и не так безопасно и… дорого.
Вот только если начнёте расширяться за пределы города, то ничего другого не останется. А так, кроме цены… Скорость большая и не нужна. На практике могу сказать, что у нас связь с филиалами осуществляется по Интернету. По rdesktop компьютеры на филиалах управляются вполне удобно, несмотря на то, что в некоторых городах интернет всё ещё медленный. А учётное ПО, установленное на них, не требует постоянной связи: все нужные данные хранятся локально в БД филиалов и потихоньку (пока есть связь) производится обмен данными между филиалами и центром. Надо сказать, что с 70 филиалами и 100 тыс. позиций номенклатуры в ассортименте объёмы данных всё ещё смехотворны. Проблемы с безопасностью решаются наладкой шифрованного VPN.
Symbian — нет, RIM — нет, Android — нет, Apple — нет.
Это не минусы технологии как таковой, а минусы политики MS.
Может она удобная? Тоже нет, в отличие от HTML5 это чуждый браузеру элемент со всеми вытекающими последствиями: фокус на странице и фокус на приложении разные, текст и там, и там одновременно не выделишь, по правой кнопке не будет меню браузера.
Удобство для разработчика? Проблемы с SEO и с той же чужеродностью.
А что, уже rich internet application, написанные на extjs (или как его теперь переименовали) с этим эффективно борются? Лично моё впечатление, что там с данным моментом не меньше граблей. Особенно радует пляска с бубном вокруг контекстного меню, которое в опере вообще никак нельзя переопределить, а нужно (ну очень нужно в каких-нибудь WYSIWYG-редакторах). И чего это хлопцы из W3C никак не придумают механизм для встраивания своих пунктов меню в контекстное меню «агента пользователя»?
Бесплатная? Нет, чтобы посмотреть надо купить Windows или переплачивать за Мак.
Дык, всё же документировано и стандартизировано. Никто не мешает взять и написать свою реализацию. Вон, чуваки из Novel замутили свою с блэк-джеком. Правда, мешает политика самих MS и политика других компаний в отношении продукции MS, ведь за еду никто не будет писать реализацию, а спонсировать не хотят. Кстати, сюда же и вопросы про удобство разработчика. Есть VS, очень хорошая но платная, есть SharpDevelop, которая недо-IDE (но всё равно, значительно удобнее, чем Eclipse/Netbeans/ещё-что-нибудь для JS). Никто не мешает написать свою IDE, как это сделано в случае с Java. Но ведь не пишут. А кто виноват? Может, хомячки, возглавляемые W3C, которые везде пихают свой любимый HTML+CSS+JS, и даже не пытаются смотреть по сторонам и делать мир лучше?
Строка в памяти — это и есть объект. Про XSLT-преобразование речи никто и не ведёт. XSLT, помимо низкой производительности, плох ещё и тем, что исходные данные для него задаются в XML. Вот если шаблонизатор в качестве исходных данных принимает объекты, то он же сможет дёргать их методы или передавать их методам других объектам (или, например, статическим методам некоторых классов). При этом никто не мешает скомпилировать XML-шаблон непосредственно в код виртуальной машины соотв. языка (если язык такое позволяет). Кстати, надо сказать, что PHP проблемы с XSLT ещё и в том, что при каждом запросе надо компилировать сам XSLT-шаблон, тогда как в других языка достаточно скомпилировать шаблон при старте сервера.
А с чего это шаблонизатор, выдающий XML, должен быть тяжелее текстового шаблонизатора? Ведь всё отличие XML-ного шаблонизатора в том, что на входе он потребует well-formed XML-документ, а на выходе заэкранирует что нужно. В текстовом шаблонизаторе на выходе получится тот же код, но за правильностью исходного шаблона с точки зрения XML и за экранирование вывода отвечает программист, а не шаблонизатор.
Перечисленные проблемы — это не проблемы Silverlight, а проблемы политики MS и сложившейся инфраструктуры. Как технология Silvelight гораздо продвинутее.
Где же он закрытый? А тупиковая весть развития «интернета» — это как раз веб в его нынешнем состоянии, ибо убог и по своим возможностям и жутко медлителен, и вообще, как бы не очень подходит для построения rich internet application, ибо по сути своей был придуман для описания гипертекста.
Какая разница, кто матюгнётся: сервер на этапе поствалидации или браузер? А то, что темплейт-системы генерируют текст, а не XML — это очень прискорбно.
Единственный неэкранированный амперсанд в ссылке, что не редкость, способен поломать страницу, и это будет обнаружено скорее всего в самый неподходящий момент.
Ну а если генерить XML не как текст, а как XML, используя DOM или какой-нибудь потоковый генератор?
Да, работают они все так же. Но внутри Hibernate использует пул по умолчанию. Кроме того, можно (и нужно в продуктиве) настраивать пул специально для Hibernate. В этом случае настройка пула выглядит несколько иначе, чем описано в статье.
Ну не совсем правильно выразился. В посте написано, что можно было бы использовать singleton, но лучше его не использовать, т.к. это пагубно скажется на производительности. А как раз поднимать только одно соединение на всё приложение чревато не столько снижением производительности, сколько невозможности одновременной обработки нескольких запросов.
Сдаётся мне, что главная причина, по которой используется пул соединений — это возможность одновременной работы нескольких потоков (threads) приложения. В противном случае потоку, который открывает транзакцию, пришлось бы ещё и тормозить остальные потоки. Кстати, странно, что используется работа с БД напрямую. Есть же JPA, есть же Hibernate. Насколько я знаю, для них пул можно настроить специфическим механизмом.
А какие нужны? Работа на всех устройствах? Ну так и HTML4 прекрасно работает на многих устройствах. Зачем нам ещё какие-то HTML5 и плагины?
Что значит «чужеродность» и чем она ущербна? Дыры в безопасности могут быть и в браузере.
Сильверлайт реализован в виде плагина, и его потому нетрудно скачать и установить, будучи даже полным профаном (в последнее время подобная операция делается в два клика). При этом пользователь кликнет куда надо, ибо у него будет красоваться сообщение c просьбой установить. Установка браузера для человека неискушённого — задача более нетривиальная.
А это «более-менее приличный вид» — это уровень цветных буковок. К тому времени, как в нём появится функционал, имеющийся в Silverlight, или хотя бы в JavaFX и Flash, может да, Silverlight успеет достаточно распространиться.
Тем не менее, когда всё-таки нужно что-то подобное, с XSLT приходится использовать костыли. Да и необходимость генерить XML, чтобы подать его на вход XSLT-шаблону несколько удручает. Ибо в случае даже с JAXB необходимо прописывать XML-схему и аннотации. Конечно, можно придумать свой костыль для простенького преобразования объектов в XML, но зачем, когда можно и без этого?
Да нет, как раз более популярным в вебе является PHP, потому и про XSLT говорят, наверное, в контексте PHP. Так вот: в Java (Ruby, Python, C#) как раз с производительностью XSLT несколько лучше, ибо можно при старте сервера скомпилировать XSLT, а не парсить его каждый раз при HTTP-запросе. XSLT в Java и PHP теоретически может работать одинаково, т.к. скорее всего и там и там дёргается нативная реализация XSLT (хотя, возможно, в Java XSLT-процессор написан на Java, но от этого хуже не становится). Вот только если насчёт Java я уверен, что Java-код работает не медленее XSLT-процессора, то от PHP можно ждать чего угодно.
А кто говорит про интерпретируемые? Я например, говорю больше про Java и .NET. Так вот там производительность шаблонизатора без XSLT должна быть выше, ибо в конечном итоге все сводится к нативным инструкция процессора, которые не работают с DOM-деревом в памяти, а сразу выводят текст. Ах да, им ещё не надо парсить входной XML.
А ничего адекватного в статье нет. Только лозунги. И сравнение со Smarty в кривых руках. Ну например:
Правда? Чего бы это вдруг шаблонизатор начал вмешиваться в бизнес-логику? А как XSLT от этого спасает? Во втором случае я вижу единственный вариант: в бизнес-логику лезет не сам шаблон, а некий слой, который вытаскивает данные и преобразует в XML. Для этого слоя даже есть название: presenter в паттерне MVP. Так вот если не устраивает MVC, то может стоит перейти на MVP? И в случае шаблонизатора без XSLT всё отличие presenter'а будет заключаться в том, что он просто вытащит данные, а не будет ещё преобразовывать их в XML.
Я тут как раз воюю с противниками «закрытых плагинов к браузеру». Ну для любителей открытых плагинов к браузеру есть Java Applets. А так, ну да, есть во флеше аналог web sockets, уже давно работающий на старых браузерах. Ну есть он и в сильверлайте. Только вот сильверлайт технически попродвинутее будет. А так да на
безрыбьеHTML5 иракFlash — рыба.На современных машинах? А ничего, что есть немалый такой контингент пользователей, юзающих IE6 и IE7, который хвалёный HTML5 не поддерживают? И они даже не могут посмотреть видео/послушать музыку без «закрытых плагинов для браузера». То же и с сокетами. Пока пошевелится w3c, пока разработчики наваяют/протестируют, пока все перейдут на IE9… Вот вам и прогресс, вот вам и развитие интернета.
Вот только если начнёте расширяться за пределы города, то ничего другого не останется. А так, кроме цены… Скорость большая и не нужна. На практике могу сказать, что у нас связь с филиалами осуществляется по Интернету. По rdesktop компьютеры на филиалах управляются вполне удобно, несмотря на то, что в некоторых городах интернет всё ещё медленный. А учётное ПО, установленное на них, не требует постоянной связи: все нужные данные хранятся локально в БД филиалов и потихоньку (пока есть связь) производится обмен данными между филиалами и центром. Надо сказать, что с 70 филиалами и 100 тыс. позиций номенклатуры в ассортименте объёмы данных всё ещё смехотворны. Проблемы с безопасностью решаются наладкой шифрованного VPN.
Это не минусы технологии как таковой, а минусы политики MS.
Может она удобная? Тоже нет, в отличие от HTML5 это чуждый браузеру элемент со всеми вытекающими последствиями: фокус на странице и фокус на приложении разные, текст и там, и там одновременно не выделишь, по правой кнопке не будет меню браузера.
Удобство для разработчика? Проблемы с SEO и с той же чужеродностью.
А что, уже rich internet application, написанные на extjs (или как его теперь переименовали) с этим эффективно борются? Лично моё впечатление, что там с данным моментом не меньше граблей. Особенно радует пляска с бубном вокруг контекстного меню, которое в опере вообще никак нельзя переопределить, а нужно (ну очень нужно в каких-нибудь WYSIWYG-редакторах). И чего это хлопцы из W3C никак не придумают механизм для встраивания своих пунктов меню в контекстное меню «агента пользователя»?
Дык, всё же документировано и стандартизировано. Никто не мешает взять и написать свою реализацию. Вон, чуваки из Novel замутили свою с блэк-джеком. Правда, мешает политика самих MS и политика других компаний в отношении продукции MS, ведь за еду никто не будет писать реализацию, а спонсировать не хотят. Кстати, сюда же и вопросы про удобство разработчика. Есть VS, очень хорошая но платная, есть SharpDevelop, которая недо-IDE (но всё равно, значительно удобнее, чем Eclipse/Netbeans/ещё-что-нибудь для JS). Никто не мешает написать свою IDE, как это сделано в случае с Java. Но ведь не пишут. А кто виноват? Может, хомячки, возглавляемые W3C, которые везде пихают свой любимый HTML+CSS+JS, и даже не пытаются смотреть по сторонам и делать мир лучше?
Ну а если генерить XML не как текст, а как XML, используя DOM или какой-нибудь потоковый генератор?