Hello, .!
You wrote on Mon, 30 Jul 2007 20:26:32 GMT:
>> Извини, но я как-то не привык телегу впереди лошади ставить, т.е. >> придумывать зачем какому-нибудь сайту может понадобиться XSLT. >> Смотреть > Ну вот тебе задача: "Если бы тебе пришлось делать сайт X, выбрал бы > ли ты xslt?". Найти такое X (желательно из существующих сайтов), > где ответ утвердительный.
Ты меня похоже не понял. Я не собираюсь искать никакой сайт X. Исходить нужно из задач.
XSLT — один из способов реализации уровня представления, принципиально ничем не хуже других. Потенциальных недостатка два (ну кроме необходимости обучения): возможный оверхед, вызванный генерацией XML и последующей трансформацией, и — в случае клентских преобразований — различия в XSLT-процессорах.
>> нужно по конкретным задачам. XSLT, как известно, позволяет >> генерировать различные представления. > Но это можно делать и на стороне сервера.
Разумеется. Но мне такой разговор начинает уже напоминать "армяне лучше чем грузины"
>>> Был аргумент "в те времена", по-моему недостаточный аргумент. >>> Что самое интересное, xslt появился примерно вместе с xml. >> Три раза ха-ха. Ты в курсе в каком году XSLT-процессоры стали >> более-менее распространены на клиенте? XML-парсеры стали доступны >> гораздо раньше (берем в качестве мерки промежуток в десять лет) > Какой ещё промежуток в десять лет??? Ты в каком году живёшь? XML - > стардарт 1998 года, XSLT — 1999 г. Есть ещё вымерший > XSL — 1998 г. тоже. Я привёл года для TR. Конечно, драфты были > ранее, но незначительно.
Ну и толку что стандарт XSLT появился в 1999-м (в самом конце кстати)?
XML-парсер стал доступен в IE 5.0, это средина 1999-го. Никакими XSLT-процессорами на клиенте тогда и не пахло. Первый клиентский XSLT-процессор появился с IE 6.0 — средина 2001-го. То есть как минимум разница в два года. Теперь смотрим общее время жизни этих технологий (декаду я взял условно, реально даже меньше) и понимаем, что "XSLT появился примерно вместе с XML" — это нонсенс. Формально стандарты появились близко, доступные же имплементации — с большой разницей.
>> В начале 2000-х выбирать как-то не приходилось. > Вот я и говорю "было".
Ну так а с чего дискуссия началась? С поиска причин непопулярности XSLT на клиенте. Свою жизнь XSLT начал "тогда", а не "сейчас".
>> Ну так ни юзер, ни приложение в адресной строке ничего не >> вводили. Там был, как это сейчас модно говорить, Ajax. > Тогда уж удобнее на js писать, имхо. Вон, тут и jQuery подвалило.
Опять же, разговор зашел о том, почему клиентский XSLT не прижился. Никакого jQuery тогда не было, да вообще ничего не было.
"XSLT vs. JS" это отдельный вопрос.
>> А насчет многословности — это собственно проблема XML-синтаксиса >> XSLT. Я тоже от этого не в восторге. > Ну... скажем, для xhtml — очень даже неплохо.
И поэтому ты утверждаешь что удобнее на JS писать?
YК wrote:
>> > Извини, но я как-то не привык телегу впереди лошади ставить, т.е. >> > придумывать зачем какому-нибудь сайту может понадобиться XSLT. >> > Смотреть >> Ну вот тебе задача: "Если бы тебе пришлось делать сайт X, выбрал бы >> ли ты xslt?". Найти такое X (желательно из существующих сайтов), >> где ответ утвердительный. > Ты меня похоже не понял. Я не собираюсь искать никакой сайт X. Исходить > нужно из задач. > XSLT — один из способов реализации уровня представления, принципиально > ничем не хуже других. Потенциальных недостатка два (ну кроме > необходимости обучения): возможный оверхед, вызванный генерацией XML и > последующей трансформацией, и — в случае клентских преобразований — > различия в XSLT-процессорах.
Ты меня тоже видимо не понял. Во-первых, я "против" только клиентского xslt. На сервере — пусть крутится. Во-вторых, мой
основной тезис — он не нужен на клиенте, ибо ничего нового не даёт.
Единственное что ты привёл в качестве плюса — уменьшить нагрузку на сервер. По-моему, это плохое оправдание. Проблемы
производительности должны решаться по-другому.
>> > гораздо раньше (берем в качестве мерки промежуток в десять лет) >> Какой ещё промежуток в десять лет??? Ты в каком году живёшь? XML - >> стардарт 1998 года, XSLT — 1999 г. Есть ещё вымерший >> XSL — 1998 г. тоже. Я привёл года для TR. Конечно, драфты были >> ранее, но незначительно. > Ну и толку что стандарт XSLT появился в 1999-м (в самом конце кстати)? > XML-парсер стал доступен в IE 5.0, это средина 1999-го. Никакими > XSLT-процессорами на клиенте тогда и не пахло. Первый клиентский > XSLT-процессор появился с IE 6.0 — средина 2001-го. То есть как минимум > разница в два года. Теперь смотрим общее время жизни этих технологий
2 года. И где десять??
> (декаду я взял условно, реально даже меньше) и понимаем, что "XSLT > появился примерно вместе с XML" — это нонсенс. Формально стандарты > появились близко, доступные же имплементации — с большой разницей.
Ну 8 и 6 лет для технологии — не велика разница.
>> > В начале 2000-х выбирать как-то не приходилось. >> Вот я и говорю "было". > Ну так а с чего дискуссия началась? С поиска причин непопулярности XSLT > на клиенте. Свою жизнь XSLT начал "тогда", а не "сейчас".
Тогда и закончил.
>> > А насчет многословности — это собственно проблема XML-синтаксиса >> > XSLT. Я тоже от этого не в восторге. >> Ну... скажем, для xhtml — очень даже неплохо. > И поэтому ты утверждаешь что удобнее на JS писать?
Да, ибо htML — язык разметки (Markup Lanugage), и для него удобно использовать xML, а вот xslt — язык преобразования
данных, ближе к языку программирования.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
YК>Ты меня похоже не понял. Я не собираюсь искать никакой сайт X. Исходить нужно из задач. YК>XSLT — один из способов реализации уровня представления, принципиально ничем не хуже других. Потенциальных недостатка два (ну кроме необходимости обучения): возможный оверхед, вызванный генерацией XML и последующей трансформацией, и — в случае клентских преобразований — различия в XSLT-процессорах.
Еще браузер не сможет отрендерить частично загруженный XML.
Здравствуйте, no4, Вы писали:
no4>Еще браузер не сможет отрендерить частично загруженный XML.
В частных случаях может. Gecko научили рендерить XHTML до полной его загрузки. Просто парсер должен предполагать, что уже загруженная часть XML валидна, и уметь "закрывать", элементы, для которых ещё не получен закрывающий тег.
Здравствуйте, anonymous, Вы писали:
A>Здравствуйте, no4, Вы писали:
no4>>Еще браузер не сможет отрендерить частично загруженный XML.
A>В частных случаях может. Gecko научили рендерить XHTML до полной его загрузки. Просто парсер должен предполагать, что уже загруженная часть XML валидна, и уметь "закрывать", элементы, для которых ещё не получен закрывающий тег.
Я имею ввиду, рендерить при помощи XSLT — есть ли готовая технология рендеренья XML при помощи XSLT?
anonymous wrote:
> no4>Еще браузер не сможет отрендерить частично загруженный XML. > > В частных случаях может. Gecko научили рендерить XHTML до полной его > загрузки. Просто парсер должен предполагать, что уже загруженная часть > XML валидна, и уметь "закрывать", элементы, для которых ещё не получен > закрывающий тег.
Ну про xslt тебе ответили, а для xml — всё проще. Есть такая штука SAX...
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Hello, .!
You wrote on Tue, 31 Jul 2007 13:03:52 GMT:
> Единственное что ты привёл в качестве плюса — уменьшить нагрузку на > сервер. По-моему, это плохое оправдание. Проблемы > производительности должны решаться по-другому.
Ага, щас. Перераспределение нагрузки между узлами — это элементарный и эффективный способ повышения производительности
>>>> гораздо раньше (берем в качестве мерки промежуток в десять лет) >>> Какой ещё промежуток в десять лет??? Ты в каком году живёшь? >>> XML - >>> стардарт 1998 года, XSLT — 1999 г. Есть ещё вымерший >>> XSL — 1998 г. тоже. Я привёл года для TR. Конечно, драфты были >>> ранее, но незначительно. >> Ну и толку что стандарт XSLT появился в 1999-м (в самом конце >> кстати)? >> XML-парсер стал доступен в IE 5.0, это средина 1999-го. Никакими >> XSLT-процессорами на клиенте тогда и не пахло. Первый клиентский >> XSLT-процессор появился с IE 6.0 — средина 2001-го. То есть как >> минимум разница в два года. Теперь смотрим общее время жизни >> этих технологий > 2 года. И где десять??
Блин. Шкала десять лет. Так понятно?
>> (декаду я взял условно, реально даже меньше) и понимаем, что >> "XSLT появился примерно вместе с XML" — это нонсенс. Формально >> стандарты появились близко, доступные же имплементации — с >> большой разницей. > Ну 8 и 6 лет для технологии — не велика разница.
Велика. Учитывая современные скорости развития технологий — велика.
>>>> А насчет многословности — это собственно проблема >>>> XML-синтаксиса >>>> XSLT. Я тоже от этого не в восторге. >>> Ну... скажем, для xhtml — очень даже неплохо. >> И поэтому ты утверждаешь что удобнее на JS писать? > Да, ибо htML — язык разметки (Markup Lanugage), и для него удобно > использовать xML, а вот xslt — язык преобразования данных, ближе к > языку программирования.
Так понятно все это. Просто ты с одной стороны утверждаешь, что XSLT для генерации XHTML — "очень даже неплохо", а с другой — что лучше на JS.
Здравствуйте, anonymous, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
A>>>Новая виртуальная машина Tamarin для ECMAScript 4 ... CS>>Это имеет какое либо отношение к XBL?
A>Да, это имеет непосредственное отношение к его потенциальной многоязычности, а также поддержке этой многоязычности в отличных от Gecko браузерах.
Слушай ты этот XBL как мантру какую повторяешь. Это просто не смешно.
Тебя просят: объясни чего он умеет сверх того что веб уже умеет или хотя бы делает лучше.
Ты же отделываешься общими заявлениями в стиле "XBL это зашибись потому что слово клевое".
Это как минимум не профессионально.
YК wrote:
>> Единственное что ты привёл в качестве плюса — уменьшить нагрузку на >> сервер. По-моему, это плохое оправдание. Проблемы >> производительности должны решаться по-другому. > Ага, щас. Перераспределение нагрузки между узлами — это элементарный и > эффективный способ повышения производительности
В общем, понятно. Для сферического сайта в вакууме это только и будет работать.
>> 2 года. И где десять?? > Блин. Шкала десять лет. Так понятно?
Нет. Что шкала десять лет?
Если округлять до десяти лет, то получится в точности ровесные технологии.
>> > (декаду я взял условно, реально даже меньше) и понимаем, что >> > "XSLT появился примерно вместе с XML" — это нонсенс. Формально >> > стандарты появились близко, доступные же имплементации — с >> > большой разницей. >> Ну 8 и 6 лет для технологии — не велика разница. > Велика. Учитывая современные скорости развития технологий — велика.
xml 2 года назад был гораздо лучше, чем клиентский xslt.
И ты правда думаешь, что через 2 года для xslt ситуация изменится в лучшую сторону? Хотя ладно, лучше не гадать.
>> >>> А насчет многословности — это собственно проблема >> >>> XML-синтаксиса >> >>> XSLT. Я тоже от этого не в восторге. >> >> Ну... скажем, для xhtml — очень даже неплохо. >> > И поэтому ты утверждаешь что удобнее на JS писать? >> Да, ибо htML — язык разметки (Markup Lanugage), и для него удобно >> использовать xML, а вот xslt — язык преобразования данных, ближе к >> языку программирования. > Так понятно все это. Просто ты с одной стороны утверждаешь, что XSLT для > генерации XHTML — "очень даже неплохо", а с другой — что лучше на JS.
Нет, сорри, я имел в виду XML-синтаксис для html неплохо.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
И это тоже, но обсуждался-то тут XBL, и ты спрашивал именно про него. Не помнишь?
CS>Слушай ты этот XBL как мантру какую повторяешь. Это просто не смешно.
CS>Тебя просят: объясни чего он умеет сверх того что веб уже умеет или хотя бы делает лучше. CS>Ты же отделываешься общими заявлениями в стиле "XBL это зашибись потому что слово клевое".
Тут четверть сотни сообщений на эту тему — читай, перечитывай.
CS>Это как минимум не профессионально.
Ты думаешь, меня волнует твоё мнение обо мне лично?
CS>>причем здесь XBL то?
A>И это тоже, но обсуждался-то тут XBL, и ты спрашивал именно про него. Не помнишь?
Ты говоришь: "Да, это имеет непосредственное отношение к его потенциальной многоязычности, а также поддержке этой многоязычности в отличных от Gecko браузерах."
Я говорю: "Многоязычность и так есть в Web, и не потенциальная, а реальная." и спрашиваю "причем здесь XBL то? что конкретно он 'многоязычит'"
CS>>Слушай ты этот XBL как мантру какую повторяешь. Это просто не смешно. A>http://rsdn.ru/forum/NewMsg.aspx?mid=2597945
CS>>Тебя просят: объясни чего он умеет сверх того что веб уже умеет или хотя бы делает лучше. CS>>Ты же отделываешься общими заявлениями в стиле "XBL это зашибись потому что слово клевое".
A>Тут четверть сотни сообщений на эту тему — читай, перечитывай.
Там ответов нет. Как минимум ни я ни Mamut ответы не нашли.
CS>>Это как минимум не профессионально.
A>Ты думаешь, меня волнует твоё мнение обо мне лично?
Мы говорим на разных языках.
Непрофессиональным является способ добавления новых фич в Web предлагаемый XBL.
Скрипт и CSS уже существуют и вместо инкрементного дополненния новых свойств
в существующие конструкции XBL предлагает подход создания новой сферической сущности
которая создает больше проблем чем решений (еще раз — мы так и не услышали каких решений).
Непрофессиональным и не этичным является также попытка навязывания внутренней имплементации
отдельно взятого UA всем остальным игрокам — при этом эта внутренняя имплементация не дает Вебу *ничего*
принципиально нового. Непрофессиональным и просто банально глупым является закрытие глаз на то что предыдущая
попытка (HTC) в общем-то провалилалсь еще лет пять как тому.
Персональным непрофессионализмом является предложение вообще рассматривать
XBL как опцию для профессионалов Web дизайна ибо Microsoft заведомо не будет делать XBL ибо у них есть HTC.
Opera насколько я понимаю не видит в ём ничего полезного для себя. Остаются Gecko и WebKit (at some extent).
Технология может победить только в том случае если заведомо известно что основные игроки
не будут против. Новая технология либо должна приносить принципально новое качество — тогда
есть мотивация ея имплементации у UA vendors — т.е. ненулевая вероятность что оно пойдет.
В любом случае сначала требуется ответить на вопрос "а могут ли существующие технологии обеспчить фичу А?"
и только в случае строго негативного ответа предлагать решение B по реализации фичи А.
Это то как проектируют профессионалы в этой отрасли.
Здравствуйте, c-smile, Вы писали:
A>>И это тоже, но обсуждался-то тут XBL, и ты спрашивал именно про него. Не помнишь? CS>Ты говоришь: "Да, это имеет непосредственное отношение к его потенциальной многоязычности, а также поддержке этой многоязычности в отличных от Gecko браузерах." CS>Я говорю: "Многоязычность и так есть в Web, и не потенциальная, а реальная." и спрашиваю "причем здесь XBL то? что конкретно он 'многоязычит'"
Нет там реальной многоязычности. От того что ты напишешь:
<script language="PythonScript"></script>
браузер не начнёт понимать Python. Конструкция есть, языков нет. Исключением является IE с его VBScript. Mamut спрашивал, как быть пользователям других браузеров, если виджет описан на языке, который поддерживается только Gecko? Так вот в начальном сообщении приводится возможный вариант решения. Причем это касается не только виджетов но и просто любых скриптов.
A>>Тут четверть сотни сообщений на эту тему — читай, перечитывай. CS>Там ответов нет. Как минимум ни я ни Mamut ответы не нашли.
Как минимум складывается впечатление, что ответы вам не были нужны. А может и... см. ниже.
CS>>>Это как минимум не профессионально. A>>Ты думаешь, меня волнует твоё мнение обо мне лично? CS>Мы говорим на разных языках.
Вполне возможно.
CS>Непрофессиональным является способ добавления новых фич в Web предлагаемый XBL. CS>Скрипт и CSS уже существуют и вместо инкрементного дополненния новых свойств CS>в существующие конструкции XBL предлагает подход создания новой сферической сущности CS>которая создает больше проблем чем решений (еще раз — мы так и не услышали каких решений).
Это не сферическая сущность, это обёртка (XML-based wrapper format) для существующих технологий, соответственно, она не должна чего-то там инкрементировать. Она влияет на качество, а не на количество.
CS>Непрофессиональным и не этичным является также попытка навязывания внутренней имплементации CS>отдельно взятого UA всем остальным игрокам — при этом эта внутренняя имплементация не дает Вебу *ничего* CS>принципиально нового. Непрофессиональным и просто банально глупым является закрытие глаз на то что предыдущая CS>попытка (HTC) в общем-то провалилалсь еще лет пять как тому.
XBL2 никоим образом не завязан на Gecko, более того, он там даже не реализован ещё. О каком навязывании внутренней имплементации тогда можно говорить? Про непрофессионализм и глуппость напиши письмо в W3C, пусть ребята посмеются.
CS>Это то как проектируют профессионалы в этой отрасли. CS>Я дико извиняюсь но сие по-моему очевидно.
Как говорил мой преподаватель по матану: "Труднее всего доказывать очевидные вещи." (:
Hello, .!
You wrote on Tue, 31 Jul 2007 18:20:22 GMT:
>>> Единственное что ты привёл в качестве плюса — уменьшить >>> нагрузку на сервер. По-моему, это плохое оправдание. Проблемы >>> производительности должны решаться по-другому. >> Ага, щас. Перераспределение нагрузки между узлами — это >> элементарный и эффективный способ повышения производительности > В общем, понятно. Для сферического сайта в вакууме это только и > будет работать.
П...ц. Я уже несколько раз русским языком сказал, что разрабатывал подобное приложение. Оно:
a) работает
б) продается за деньги
в) его покупают и используют
>>> 2 года. И где десять?? >> Блин. Шкала десять лет. Так понятно? > Нет. Что шкала десять лет? > Если округлять до десяти лет, то получится в точности ровесные > технологии.
Так, ладно. Буду разжевывать.
С момента появления технология XSLT позиционировалась как приятное и полезное добавление к XML. Реально же разработчика, пожелавшего использовать XSLT на клиенте ожидал облом: XSLT-процессоры там стали более-менее распространены в 2002-2003-м. Поэтому до момента повсеместного распространения XSLT-процессоров XML и XSLT были совершенно не равновесными технологиями.
>>>> (декаду я взял условно, реально даже меньше) и понимаем, что >>>> "XSLT появился примерно вместе с XML" — это нонсенс. Формально >>>> стандарты появились близко, доступные же имплементации — с >>>> большой разницей. >>> Ну 8 и 6 лет для технологии — не велика разница. >> Велика. Учитывая современные скорости развития технологий — >> велика. > xml 2 года назад был гораздо лучше, чем клиентский xslt. > И ты правда думаешь, что через 2 года для xslt ситуация изменится в > лучшую сторону? Хотя ладно, лучше не гадать.
Я так не думаю, какой-то непонятный вывод. 2 года — это то, что сыграло свою роль в прошлом. Поезд ушел, все.
YК wrote:
> П...ц. Я уже несколько раз русским языком сказал, что разрабатывал > подобное приложение. Оно: > a) работает > б) продается за деньги > в) его покупают и используют
И многие выставляют опцию "использовать client-side xslt"?
Ты точно уверен, что если бы этот проект написали без xslt вообще, то он бы не продавался и не работал?
>> >> 2 года. И где десять?? >> > Блин. Шкала десять лет. Так понятно? >> Нет. Что шкала десять лет? >> Если округлять до десяти лет, то получится в точности ровесные >> технологии. > Так, ладно. Буду разжевывать. > С момента появления технология XSLT позиционировалась как приятное и > полезное добавление к XML. Реально же разработчика, пожелавшего > использовать XSLT на клиенте ожидал облом: XSLT-процессоры там стали > более-менее распространены в 2002-2003-м. Поэтому до момента > повсеместного распространения XSLT-процессоров XML и XSLT были > совершенно не равновесными технологиями.
Это я понял. Я спрашиваю, что ты имел в виду под 10 годами? Или просто оговорка?
> Я так не думаю, какой-то непонятный вывод. 2 года — это то, что сыграло > свою роль в прошлом. Поезд ушел, все.
Может быть, сложно судить. Некоторые технологии ведут себя совершенно наоборот: забываются, потом возрождаются.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Hello, .!
You wrote on Fri, 03 Aug 2007 12:22:36 GMT:
>> П...ц. Я уже несколько раз русским языком сказал, что >> разрабатывал подобное приложение. Оно: >> a) работает >> б) продается за деньги >> в) его покупают и используют > И многие выставляют опцию "использовать client-side xslt"?
Насколько я знаю, преобразования на сервере никто не использует. Зачем, если все прекрасно работает на клиенте?
> Ты точно уверен, что если бы этот проект написали без xslt вообще, > то он бы не продавался и не работал?
Я предпочитаю не фантазировать. Потом, я кажется не выдаю XSLT за серебрянную пулю.
>> С момента появления технология XSLT позиционировалась как >> приятное и полезное добавление к XML. Реально же разработчика, >> пожелавшего использовать XSLT на клиенте ожидал облом: >> XSLT-процессоры там стали более-менее распространены в >> 2002-2003-м. Поэтому до момента повсеместного распространения >> XSLT-процессоров XML и XSLT были совершенно не равновесными >> технологиями. > Это я понял. Я спрашиваю, что ты имел в виду под 10 годами? Или > просто оговорка?
Не оговорка. Два года для технологии, которой не исполнилось и десяти — серьезный срок.
