Зачем нужен XSLT? [Re: что такое UML?]
по ходу не знаешь 
Ну расскажи, где ты умело применил XSLT, поделись опытом!
XLST:
1) медленный
2) сложный для кодирования (заметь, уже не "кодер" в Яндексе, а прогламмист!
)
3) не имеет никаких преимуществ перед другими шаблонизаторами
Тем не менее, есть упертые дураки, которые "внедряют высокую технологию" на каждом углу. Как результат -- ничего не работает и тормозит.
Насчет Яндекса: там НЕТ xslt, и они от него явно отказываются, если он есть по мелочам.
1) медленный
2) сложный для кодирования (заметь, уже не "кодер" в Яндексе, а прогламмист!
)3) не имеет никаких преимуществ перед другими шаблонизаторами
Тем не менее, есть упертые дураки, которые "внедряют высокую технологию" на каждом углу. Как результат -- ничего не работает и тормозит.
Насчет Яндекса: там НЕТ xslt, и они от него явно отказываются, если он есть по мелочам.
а зачем тогда они ищут XSLT "программиста" ? 
другими шаблонизаторамиА какие есть другие шаблонизаторы? Умело составленные регекспы?
Реально не знаешь ни одного?
Скорее всего, у них уже кто-то написал что-то, и теперь чтобы что-то менять выгоднее держать программиста отдельного, чем переписывать на другой шаблонизатор.
Если это не так, и сейчас строится проект на основе XSLT, то можно только посочувствовать -- пидорасы упертые везде есть, почему бы нашему милашке не оказаться руководителем проекта в компании Яндекс?
Если это не так, и сейчас строится проект на основе XSLT, то можно только посочувствовать -- пидорасы упертые везде есть, почему бы нашему милашке не оказаться руководителем проекта в компании Яндекс?
>Насчет Яндекса: там НЕТ xslt, и они от него явно отказываются, если он есть по мелочам.
Ааааааааааааааа! Жеееееееееееесть!
Я ща пойду и расскажу об этом нашей верстке
Ааааааааааааааа! Жеееееееееееесть!
Я ща пойду и расскажу об этом нашей верстке Да, кстати, чтобы в будущем не писать такие глупости: http://yandex.ru/yandsearch?text=%FF%ED%E4%E5%EA%F1+xslt&stype=www
DTD знаю.
Но он скучнее, чем XSLT.
Но он скучнее, чем XSLT.
Ну возьми самый простой шаблонизатор: HTML-код, со вставками: %REKLAMA_VERH%, %IMIA_USERA%, %TEXT_MSG%. Такой работает на ура даже на примитивных реплейсках. Добавь в нему циклы, условия и "скобки" (типа %REKLAMA(VERH)%, %REKLAMA(BOK)%) и ты получишь чуть ли не машину тьюринга. В чем проблема?
Объясни мне, чем мой шаблонизатор хуже XSLT?
Да, таких шаблонизаторов -- на каждом углу как мух, потому что легче самому написать иногда чем шаблонизатор искать.
Объясни мне, чем мой шаблонизатор хуже XSLT?
Да, таких шаблонизаторов -- на каждом углу как мух, потому что легче самому написать иногда чем шаблонизатор искать.
> Реально не знаешь ни одного?
Универсальных (когда почти все-что угодно можно запихнуть во все что угодно) - нет.
Максимально приближенный к этой идеи - XSLT все-таки.
Также есть куча узкоспециализированных шаблонизаторов.
Универсальных (когда почти все-что угодно можно запихнуть во все что угодно) - нет.
Максимально приближенный к этой идеи - XSLT все-таки.
Также есть куча узкоспециализированных шаблонизаторов.
Согласен, в случае HTML-кода можно применить свой шаблонизатр.
А если, например, дело касается RPC?
А если, например, дело касается RPC?
> Объясни мне, чем мой шаблонизатор хуже XSLT?
тем, что синтаксис запросов - знаешь только ты один.
а также тем, что кучу вкусных запросов твой шаблонизатор не поддерживает.
как, например, будет выглядить вывод табличных данных?
ps
почему ты считаешь, что такой шаблонизатор будет работать быстрее, чем на XsLT?
тем, что синтаксис запросов - знаешь только ты один.
а также тем, что кучу вкусных запросов твой шаблонизатор не поддерживает.
как, например, будет выглядить вывод табличных данных?
ps
почему ты считаешь, что такой шаблонизатор будет работать быстрее, чем на XsLT?
Чем будет хуже, если будет так:
HTML-код, со вставками: %Eval("Reklama/Verh")%, %Eval("User/Name")%, %Eval("User/Message")%.
HTML-код, со вставками: %Eval("Reklama/Verh")%, %Eval("User/Name")%, %Eval("User/Message")%.
Не, ну не всем дано понять так скоро, что xslt сосет. Уже первая ласточка -- спецов по нему нет (язык-то сложный! а человеку, который его освоит быстро, надо много платить. Уже сама массивность подхода к поиску программиста чего стоит.
Преобразовывать что угодно во что угодно и машиной Тьюринга можно, только надо ли?
Для веба есть нормальные средства, можешь называть их узкоспециализированными, но в данном случае это скорее достоинство.
Для веба есть нормальные средства, можешь называть их узкоспециализированными, но в данном случае это скорее достоинство.
Говорят, что XQuery всех порулит.
Когда перестанет тормозить, конечно же.
Когда перестанет тормозить, конечно же.
> но в данном случае это скорее достоинство.
имхо. нет.
потому что и Sun, и Microsoft активно засовывает подобие XSLT и в базу, и в Jsp/Asp.net - стремясь получить единую систему/язык выборки данных
есть даже попытки засунуть XSLT прямо в язык программирования
имхо. нет.
потому что и Sun, и Microsoft активно засовывает подобие XSLT и в базу, и в Jsp/Asp.net - стремясь получить единую систему/язык выборки данных
есть даже попытки засунуть XSLT прямо в язык программирования
> Говорят, что XQuery всех порулит
имхо, XSLT и XQuery можно сильно не разделять - т.к. принципы у них одни и те же, только чуть разная специализация:
XQuery - это запросы, а XSLT - форматирование документа.
имхо, XSLT и XQuery можно сильно не разделять - т.к. принципы у них одни и те же, только чуть разная специализация:
XQuery - это запросы, а XSLT - форматирование документа.
как, например, будет выглядить вывод табличных данных?А в чем проблема? Если нужны несколько строк -- есть циклы. Если не нужны -- делаешь заготовку и просто тупо вставляешь места для расстановки всей хуйни.
для меня средство от крупной фирмы - не обязательно самое эффективное
поэтому преобразование между машинно-читаемыми форматами (уложить документ в базу и генерация представления для человека (преобразовать в HTML для отдачи в браузер) - разные задачи, заслуживающие специализированных инструментов
поэтому преобразование между машинно-читаемыми форматами (уложить документ в базу и генерация представления для человека (преобразовать в HTML для отдачи в браузер) - разные задачи, заслуживающие специализированных инструментов
вы мне наконец объясните, чем это всё лучше, чем простое использование БД...
> Преобразовывать что угодно во что угодно и машиной Тьюринга можно, только надо ли?
Речь же идет не просто о преобразовании, а о стандартизации формата запросов на сложных данных.
т.е. речь идет о том, что sql-сильно завязан на таблицы, и нужен новый язык - который позволит удобно записывать запросы к сложно-организованным данным
Речь же идет не просто о преобразовании, а о стандартизации формата запросов на сложных данных.
т.е. речь идет о том, что sql-сильно завязан на таблицы, и нужен новый язык - который позволит удобно записывать запросы к сложно-организованным данным
> Речь же идет не просто о преобразовании, а о стандартизации формата
> запросов на сложных данных.
Мы говорили про "шаблонизаторы". Это, как я понимаю, средства для генерации понятного человеку представления данных, отделяющие контент от представления.
> запросов на сложных данных.
Мы говорили про "шаблонизаторы". Это, как я понимаю, средства для генерации понятного человеку представления данных, отделяющие контент от представления.
> для меня средство от крупной фирмы - не обязательно самое эффективное
максимально эффективное в чем? в производительности? это жизненно необходимо?
> поэтому преобразование между машинно-читаемыми форматами (уложить документ в базу и генерация
> представления для человека (преобразовать в HTML для отдачи в браузер) - разные задачи, заслуживающие
> специализированных инструментов
ты уже берешь две противоположные задачи: запись в базу, и получение его обратно.
а давай возьмем только чтение.
Как выглядит получение данных сейчас:
1. Получить данные из базы: Sql
2. получить данные из внутренних источников: любимый язык программирования
3. Сформировать страницу: узкоспециализированный шаблонизатор
4. "Расскрасить" страницу на основе пожеланий пользователя: css
Почему нельзя на всех этих этапах стандартизовать формат запросов на данные?
т.е. речь не идет о том, что все эти 4-этапа будет выполнять одна и та же программа, речь идет только о том, что на каждом из этапов мы можем использовать один и тот же формат запросов для получения данных
Дополнение:
есть еще этап 3.5:
подправить страницу под ограничения браузера клиента
максимально эффективное в чем? в производительности? это жизненно необходимо?
> поэтому преобразование между машинно-читаемыми форматами (уложить документ в базу и генерация
> представления для человека (преобразовать в HTML для отдачи в браузер) - разные задачи, заслуживающие
> специализированных инструментов
ты уже берешь две противоположные задачи: запись в базу, и получение его обратно.
а давай возьмем только чтение.
Как выглядит получение данных сейчас:
1. Получить данные из базы: Sql
2. получить данные из внутренних источников: любимый язык программирования
3. Сформировать страницу: узкоспециализированный шаблонизатор
4. "Расскрасить" страницу на основе пожеланий пользователя: css
Почему нельзя на всех этих этапах стандартизовать формат запросов на данные?
т.е. речь не идет о том, что все эти 4-этапа будет выполнять одна и та же программа, речь идет только о том, что на каждом из этапов мы можем использовать один и тот же формат запросов для получения данных
Дополнение:
есть еще этап 3.5:
подправить страницу под ограничения браузера клиента
> Мы говорили про "шаблонизаторы". Это, как я понимаю, средства для генерации понятного человеку представления данных, отделяющие контент от представления.
да.
но что такое контент сейчас?
это sql БД + некие структуры данных на любимом языке + какие-то файлы в каком-то формате.
да.
но что такое контент сейчас?
это sql БД + некие структуры данных на любимом языке + какие-то файлы в каком-то формате.
> максимально эффективное в чем?
пофиг (кроме вырожденных случаев размер фирмы - не главный критерий
> Почему нельзя на всех этих этапах стандартизовать формат запросов на
> данные?
Можно, так же как можно, если напрячься, писать все программы на одном языке.
Не нужно, по той же причине.
пофиг (кроме вырожденных случаев размер фирмы - не главный критерий
> Почему нельзя на всех этих этапах стандартизовать формат запросов на
> данные?
Можно, так же как можно, если напрячься, писать все программы на одном языке.
Не нужно, по той же причине.
> Можно, так же как можно, если напрячься, писать все программы на одном языке.
> Не нужно, по той же причине.
По какой?
т.е. ты можешь показать - что ты постоянно работаешь с очень по разному организованными данными?
для которых обязательно должно быть несколько разных языков?
приведи, пожалуйста, примеры - этих очень по разному организованных данных
> Не нужно, по той же причине.
По какой?
т.е. ты можешь показать - что ты постоянно работаешь с очень по разному организованными данными?
для которых обязательно должно быть несколько разных языков?
приведи, пожалуйста, примеры - этих очень по разному организованных данных
Как выглядит получение данных сейчас:А зачем?
1. Получить данные из базы: Sql
2. получить данные из внутренних источников: любимый язык программирования
3. Сформировать страницу: узкоспециализированный шаблонизатор
4. "Расскрасить" страницу на основе пожеланий пользователя: css
Почему нельзя на всех этих этапах стандартизовать формат запросов на данные?
т.е. речь не идет о том, что все эти 4-этапа будет выполнять одна и та же программа, речь идет только о том, что на каждом из этапов мы можем использовать один и тот же формат запросов для получения данных
это все равно, как разрезать одну печатную плату на 4 куска и потом соединть одинаковыми шлейфами...
Вот скажи, тебе нужна бала бы мамка, порезаная на 4 куска - проц, память/харды, интерфейсы (pci/agp etc интерфейсы внешнего оборудования - и соединенная ОДИНАКОВЫМИ шлейфами?
Ну и нахера одинаковость тогда нужна? XSLT - как панацея для одинаковости не катит....
xml - еще да, там просто древовидная структура данных, его можно куда нить впихнуть... для реализации хранени спец инфы..
> имхо, XSLT и XQuery можно сильно не разделять - т.к. принципы у них одни и те же
Какие же?
Какие же?
> XSLT - как панацея для одинаковости не катит
XSLT - да, никатить скорее всего
а вот XPath или XQuery - уже похоже на правду.
XSLT - да, никатить скорее всего
а вот XPath или XQuery - уже похоже на правду.
> приведи, пожалуйста, примеры - этих очень по разному организованных данных
таблица с несколькими индексами, и ветвистое дерево - довольно разные организации данных
таблица с несколькими индексами, и ветвистое дерево - довольно разные организации данных
XSLT - это симптом
а болезнь называется XML.
а болезнь называется XML.
уточню: из XSLT в рамках данного треда меня интересует только XPath.
> Какие же?
формирование запросов - к данным организованным по сетевым методам, а не только по реляционным.
> Какие же?
формирование запросов - к данным организованным по сетевым методам, а не только по реляционным.
> но что такое контент сейчас?
> это sql БД + некие структуры данных на любимом языке + какие-то файлы в
> каком-то формате.
А на выходе HTML в случае веба, и для этого частного случае есть неплохие инструменты.
> это sql БД + некие структуры данных на любимом языке + какие-то файлы в
> каком-то формате.
А на выходе HTML в случае веба, и для этого частного случае есть неплохие инструменты.
разговор идет за XSLT а не че то там Patch или Q что то там...
и не об XML кстати тоже....
Я так понял, что обсуждается успех/провал чисто реализации XSLT и ее необходисомть/заменяемость...
и не об XML кстати тоже....
Я так понял, что обсуждается успех/провал чисто реализации XSLT и ее необходисомть/заменяемость...
> таблица с несколькими индексами, и ветвистое дерево - довольно разные организации данных
и? где здесь разница с точки зрения построения запросов?
для первого варианта: запрос будет вида:
select ... where Field1=@Field1
для второго:
select child_element where bla-bla from (select top_element where другая-bla-bla)
или
select * from произвольный_уровень where bla-bla
и? где здесь разница с точки зрения построения запросов?
для первого варианта: запрос будет вида:
select ... where Field1=@Field1
для второго:
select child_element where bla-bla from (select top_element where другая-bla-bla)
или
select * from произвольный_уровень where bla-bla
> А на выходе HTML в случае веба, и для этого частного случае есть неплохие инструменты
а если Pdf, то что делать?
а если Pdf, то что делать?
для второго:неа, без рекурсии (или её замены) никак
select child_element where bla-bla from (select top_element where другая-bla-bla)
или
select * from произвольный_уровень where bla-bla
даже поддерево не обойти
> уточню: из XSLT в рамках данного треда меня интересует только XPath.
> формирование запросов - к данным организованным по сетевым методам, а не только по реляционным.
Возможность выполнить XPath запрос ещё не заслуживает громкого названия "общие принципы".
Подход к обработке данных в XSLT и XQuery совершенно разный.
Не говоря уже о том, что XQuery имеет человеческий синтаксис, строгую типизацию
и является функциональным языком (разработчики Haskell постарались).
> формирование запросов - к данным организованным по сетевым методам, а не только по реляционным.
Возможность выполнить XPath запрос ещё не заслуживает громкого названия "общие принципы".
Подход к обработке данных в XSLT и XQuery совершенно разный.
Не говоря уже о том, что XQuery имеет человеческий синтаксис, строгую типизацию
и является функциональным языком (разработчики Haskell постарались).
> на выходе HTML в случае веба, и для этого частного случае есть неплохие инструменты.
приведи, пожалуйста, пример этих неплохих инструментов
Эти инструменты поддерживают формирование HTML на основе пожеланий пользователя, а также возможностей его клиента?
приведи, пожалуйста, пример этих неплохих инструментов
Эти инструменты поддерживают формирование HTML на основе пожеланий пользователя, а также возможностей его клиента?
XSLT - это симптомКатегорически не согласен. XML хорош для стандартизации передачи данных. Сувать его везде не надо, а вот использовать нормально -- можно.
а болезнь называется XML.
Как пример -- новостные ленты и пр. Я конaиги люблю хранить в xml, например, и много еще где.
Да, xslt можно применять тоже, если не важна скорость реализации. Например, для генерирования статики -- отчетов, новостных лент и пр. Но вставлять его на динамичном сайте -- пиздец как неправильно.
> неа, без рекурсии (или её замены) никак
слово ось (направление движения) тебе ничего не говорит?
Зачем нам рекурсия - если можно просто сказать, что мы сейчас движемся в другом направлении(используем другой визитер)?
слово ось (направление движения) тебе ничего не говорит?
Зачем нам рекурсия - если можно просто сказать, что мы сейчас движемся в другом направлении(используем другой визитер)?
> Подход к обработке данных в XSLT и XQuery совершенно разный.
XSLT и XQuery - имеют общее подмножество XPath.
> Возможность выполнить XPath запрос ещё не заслуживает громкого названия "общие принципы".
Почему?
сам по себе XPath очень и очень мощная штука, особенно если он умеет поддерживать внутренние механизмы организации данных (индексы, кэши и т.д.)
XSLT и XQuery - имеют общее подмножество XPath.
> Возможность выполнить XPath запрос ещё не заслуживает громкого названия "общие принципы".
Почему?
сам по себе XPath очень и очень мощная штука, особенно если он умеет поддерживать внутренние механизмы организации данных (индексы, кэши и т.д.)
> Эти инструменты поддерживают формирование HTML на основе пожеланий
> пользователя, а также возможностей его клиента?
Как обычно, разные шаблоны для разных возможностей (для упрощения есть конструкции if, чтоб не дублировать зря остальное оформление).
HTML::Template - вроде простая штука, а умеет такое.
> пользователя, а также возможностей его клиента?
Как обычно, разные шаблоны для разных возможностей (для упрощения есть конструкции if, чтоб не дублировать зря остальное оформление).
HTML::Template - вроде простая штука, а умеет такое.
и этим действительно можно пользоваться?
т.е. можно за это посадить дизайнера (не программиста) и он не испугается?
можно за это посадить эргономиста и он тоже не испугается?
или ты проповедуешь принцип: что между человеком и машиной - обязательно должен быть кодер (повелитель машин)?
т.е. можно за это посадить дизайнера (не программиста) и он не испугается?
можно за это посадить эргономиста и он тоже не испугается?
или ты проповедуешь принцип: что между человеком и машиной - обязательно должен быть кодер (повелитель машин)?
> т.е. можно за это посадить дизайнера (не программиста) и он не испугается?
хз
для XSLT яндекс тоже ищет программиста, а не дизайнера
отцы говорили, что дизайнера надо сажать за разработку примера страницы, с конкретными данными, а дальше программист смотрит на свёрстанный html-код, и заменяет конкретные данные переменными - получается шаблон
имхо, правдоподобно
хз
для XSLT яндекс тоже ищет программиста, а не дизайнера
отцы говорили, что дизайнера надо сажать за разработку примера страницы, с конкретными данными, а дальше программист смотрит на свёрстанный html-код, и заменяет конкретные данные переменными - получается шаблон
имхо, правдоподобно
можно посадить и успокоительного дать что бы не пугался.
я, конечно, программист, но все же не могу понять в чем заключается страх использования XSLT ?
пробовал на нем писать преобразования ни какого страха. кошмаров тоже потом не снилось.
я, конечно, программист, но все же не могу понять в чем заключается страх использования XSLT ?
пробовал на нем писать преобразования ни какого страха. кошмаров тоже потом не снилось.
Да, человека, который способен на подобную замену, я считаю программистом - не по названию должности, а по возможностям.
хотя, такой вариант --- дизайнер+программер мне тоже больше нравится.
Вопрос, а нахуя?
Нахуя использовать такую сложную, тяжелую и неповоротливую машину как xslt?
Нахуя использовать такую сложную, тяжелую и неповоротливую машину как xslt?
> отцы говорили, что дизайнера надо сажать за разработку примера страницы, с конкретными данными,
это все ты хорошо говоришь.
но что происходит - если в середине этого процесса - приходит заказчик и говорит, что он хочет все тоже самое, но чуть-чуть по другому?
дизайнер сдвигает пару элементов на диаграммке, а программист выкидывает весь старый код, и пишет все заново?
или другой сценарий:
прошел год, проект все это поддерживался - модифицировался и т.д.
приходит заказчик - говорит у меня тут произошли изменения надо добавить.
дизайнер - говорит "сейчас все сделаем", и достает свои диаграммы, подправляет эти свои диаграммки и отдает программисту, на что программист в ужасе отвечает: "да, ведь у нас уже полгода как все не так".
Какие дальнешие действия дизайнера и программиста?
ps
хороший шаблонизатор - в идеале - позволяет разнести все 4 фазы:
1. формирование костяка документа
2. учет пожеланий пользователя
3. учет требований программы, отображающей контент
pps
Ты же вроде проповедушь разделение представление и контента?
а сам предлагаешь запихать все в одну большую страшную кучу.
это все ты хорошо говоришь.
но что происходит - если в середине этого процесса - приходит заказчик и говорит, что он хочет все тоже самое, но чуть-чуть по другому?
дизайнер сдвигает пару элементов на диаграммке, а программист выкидывает весь старый код, и пишет все заново?
или другой сценарий:
прошел год, проект все это поддерживался - модифицировался и т.д.
приходит заказчик - говорит у меня тут произошли изменения надо добавить.
дизайнер - говорит "сейчас все сделаем", и достает свои диаграммы, подправляет эти свои диаграммки и отдает программисту, на что программист в ужасе отвечает: "да, ведь у нас уже полгода как все не так".
Какие дальнешие действия дизайнера и программиста?
ps
хороший шаблонизатор - в идеале - позволяет разнести все 4 фазы:
1. формирование костяка документа
2. учет пожеланий пользователя
3. учет требований программы, отображающей контент
pps
Ты же вроде проповедушь разделение представление и контента?
а сам предлагаешь запихать все в одну большую страшную кучу.
повторяю.
во-первых, лично для меня она неоказалась ни сложной ни тяжелой ни громоздкой.
(это я намекаю на то, что если бы ты обосновал свое мнение, либо привел варианты использования других систем, такого бы вопроса не было)
во-вторых, ИМХО вопрос все-таки сводится к тому, зачем вообще использовать технологию XML
(т.к. единственная альтернатива XSLT, что я замети в этом треде, касалась использования вместо XSLT
связки SQL и еще что-то там, ну в смысле чистых реляционных БД и преобразований написанных на любом языке программирования)
вопрос имеет место, но ответов на него тоже масса.
Самый стандартный ответ: для того, что бы оперировать данными относящимися к разным типам, но в одном формате.(коряво сказал)
во-первых, лично для меня она неоказалась ни сложной ни тяжелой ни громоздкой.
(это я намекаю на то, что если бы ты обосновал свое мнение, либо привел варианты использования других систем, такого бы вопроса не было)
во-вторых, ИМХО вопрос все-таки сводится к тому, зачем вообще использовать технологию XML
(т.к. единственная альтернатива XSLT, что я замети в этом треде, касалась использования вместо XSLT
связки SQL и еще что-то там, ну в смысле чистых реляционных БД и преобразований написанных на любом языке программирования)
вопрос имеет место, но ответов на него тоже масса.
Самый стандартный ответ: для того, что бы оперировать данными относящимися к разным типам, но в одном формате.(коряво сказал)
>Нахуя использовать такую сложную, тяжелую и неповоротливую машину как xslt?
Она универсальна.
Да, за универсальность, как правило, надо платить эффективностью.
И такая ситуация далеко не только с XSLT. Она повсеместна.
Она универсальна.
Да, за универсальность, как правило, надо платить эффективностью.
И такая ситуация далеко не только с XSLT. Она повсеместна.
ёжкин кот...
А в чем проблема чуть-чуть переделать верстку? Да пусть ту же диаграмму. Изначально делается всё под то, что это всё будет изменяться. Или я просто в виде базы всю структуру документов у себя в башке изначально организовываю, или тогда я не понимаю, на хренеа нужны все эти иксымэли. У меня это как с линуксом - который год пытаюсь понять, ЗАЧЕМ, а конкретных примеров не вижу.
А в чем проблема чуть-чуть переделать верстку? Да пусть ту же диаграмму. Изначально делается всё под то, что это всё будет изменяться. Или я просто в виде базы всю структуру документов у себя в башке изначально организовываю, или тогда я не понимаю, на хренеа нужны все эти иксымэли. У меня это как с линуксом - который год пытаюсь понять, ЗАЧЕМ, а конкретных примеров не вижу.
> с конкретными данными, а дальше программист смотрит на свёрстанный html-код, и заменяет конкретные данные переменными - получается шаблон
имхо, правдоподобно
Как дизайнер - показывает, а программист - понимает, что происходит - если данных 0 или наоборот очень много?
как дизайнер фиксирует на рисунке - что вот этот размер не меняется, а вот это плавающий в зависимости от кол-ва данных?
как дизайнер может увидеть, что он не забыл какие-то подводные камни - например, что меню - не занимает весь экран - в отдельных случаях - когда в это меню запихивается очень много команд?
имхо, правдоподобно
Как дизайнер - показывает, а программист - понимает, что происходит - если данных 0 или наоборот очень много?
как дизайнер фиксирует на рисунке - что вот этот размер не меняется, а вот это плавающий в зависимости от кол-ва данных?
как дизайнер может увидеть, что он не забыл какие-то подводные камни - например, что меню - не занимает весь экран - в отдельных случаях - когда в это меню запихивается очень много команд?
> дизайнер сдвигает пару элементов на диаграммке
какой диаграммке?
ты про архитектора проекта что ли?
ну так он, в моём представлении
1) должен уметь программировать
2) не должен лезть в описания шаблонов и преобразований - на это кодеры есть
какой диаграммке?
ты про архитектора проекта что ли?
ну так он, в моём представлении
1) должен уметь программировать
2) не должен лезть в описания шаблонов и преобразований - на это кодеры есть
для того, что бы оперировать данными относящимися к разным типам, но в одном формате.ничего не понял.
Тебе минус, если ты не видишь очевидные недостатки xslt:
1. сложность обучения кодера (что проще, найти кодера на html или xslt?)
2. медленность работы
>> Подход к обработке данных в XSLT и XQuery совершенно разный.
> XSLT и XQuery - имеют общее подмножество XPath.
>> Возможность выполнить XPath запрос ещё не заслуживает громкого названия "общие принципы".
> Почему?
Именно потому, что XPath - только подмножество, а логика верхнего уровня разная.
И вообще, тут про шаблонизаторы говорилось, а с твоим подходом получается,
что самодельный скрипт на перле, достающий данные из xml с помощью XPath и укладывающий
их в самодельные же шаблоны, построен на тех же самых "общих принципах"
и должен рассматриваться на равных с XSLT.
> XSLT и XQuery - имеют общее подмножество XPath.
>> Возможность выполнить XPath запрос ещё не заслуживает громкого названия "общие принципы".
> Почему?
Именно потому, что XPath - только подмножество, а логика верхнего уровня разная.
И вообще, тут про шаблонизаторы говорилось, а с твоим подходом получается,
что самодельный скрипт на перле, достающий данные из xml с помощью XPath и укладывающий
их в самодельные же шаблоны, построен на тех же самых "общих принципах"
и должен рассматриваться на равных с XSLT.
1.
сорри, что вмешиваюсь, но по-моему суть действий программиста, что бы на выходе получить в точности такой HTML-код, какой был у дизайнера.
так что таких непоняток не должно возникать.
2. на счет изменений в проекте по предложению заказчика:
В чем сложность поменять код XSLT больше, нежели менять код шаблонов в связке
SQL+свой преобразователь.
Или даже больше чем сложность менять код статического HTML?
//имхо сложность одна и таже, т.к. все же XSLT и направлен на то, что бы содержание могло изменяться, да и оформление поправить не составило труда.
сорри, что вмешиваюсь, но по-моему суть действий программиста, что бы на выходе получить в точности такой HTML-код, какой был у дизайнера.
так что таких непоняток не должно возникать.
2. на счет изменений в проекте по предложению заказчика:
В чем сложность поменять код XSLT больше, нежели менять код шаблонов в связке
SQL+свой преобразователь.
Или даже больше чем сложность менять код статического HTML?
//имхо сложность одна и таже, т.к. все же XSLT и направлен на то, что бы содержание могло изменяться, да и оформление поправить не составило труда.
> А в чем проблема чуть-чуть переделать верстку?
потому что обычно это не получается.
ты когда-нибудь пытался сделать большую страницу, которая одиннаково хорошо показывается в каком-нибудь текстовом браузере, в браузере на экране КПК, а также в обычном браузере.
При этом чтобы если браузер умеет поддерживать последние технологии (например, JavaScript, Flash, динамическую подгрузку частей страницы) - это тоже поддерживалось.
Сколько кода у тебя при этом было в странице?
Сколько кода надо будет переписать, если к тебе придет дизайнер и скажет, что теперь меню слева, а не сверху?
Сколько ошибок ты допустишь при таком переписывании?
потому что обычно это не получается.
ты когда-нибудь пытался сделать большую страницу, которая одиннаково хорошо показывается в каком-нибудь текстовом браузере, в браузере на экране КПК, а также в обычном браузере.
При этом чтобы если браузер умеет поддерживать последние технологии (например, JavaScript, Flash, динамическую подгрузку частей страницы) - это тоже поддерживалось.
Сколько кода у тебя при этом было в странице?
Сколько кода надо будет переписать, если к тебе придет дизайнер и скажет, что теперь меню слева, а не сверху?
Сколько ошибок ты допустишь при таком переписывании?
Имхо все варианты с меню, размерами и всем таким описываются в ТЗ... на то оно и пишется...
И уже судя по ТЗ работают и дизайнер и программер и все остальные...
а если клиент хочет что либо поменять после принятия - этот вопрос решается деньгами, новым ТЗ и т.д.
Т.е. в идеале, все что выходит за пределы принятого ТЗ - есть новый этап работы, который невозможно и ненужно включать в изначальную разработку...
И уже судя по ТЗ работают и дизайнер и программер и все остальные...
а если клиент хочет что либо поменять после принятия - этот вопрос решается деньгами, новым ТЗ и т.д.
Т.е. в идеале, все что выходит за пределы принятого ТЗ - есть новый этап работы, который невозможно и ненужно включать в изначальную разработку...
> так что таких непоняток не должно возникать.
непоняток - обычно дохера - особенно если надо сделать резиновый интерфейс, а не статический
непоняток - обычно дохера - особенно если надо сделать резиновый интерфейс, а не статический
> какой диаграммке?
диаграммке костяка страницы - что вот слева у нас меню, в центре - данные, снизу выбранный элемент и т.д.
диаграммке костяка страницы - что вот слева у нас меню, в центре - данные, снизу выбранный элемент и т.д.
> Или я просто в виде базы всю структуру документов у себя в башке изначально организовываю,
Даже если у тебя тысяча таблиц?
Даже если у тебя тысяча таблиц?
html кодер будет в реальном времени генерить страницы с динамически изменяемым контентом?
закодить html в 1000 страниц имхо сложнее, чем 1 страницу xslt.
// про медленнотсь не спорю.
закодить html в 1000 страниц имхо сложнее, чем 1 страницу xslt.
// про медленнотсь не спорю.
> а если клиент хочет что либо поменять после принятия - этот вопрос решается деньгами, новым ТЗ и т.д.
я, надеюсь, ты понимаешь, что ты на этом теряешь что-то важное?
я, надеюсь, ты понимаешь, что ты на этом теряешь что-то важное?
пример реально работающего проекта с 1000 таблиц в студию!
XML хорош для стандартизации передачи данных. Сувать его везде не надо, а вот использовать нормально -- можно.Эээ а в чем конкретно стандартизация? Могу ли взять XML из одной новостной ленты и засунуть в другую?
Как пример -- новостные ленты и пр.
Единственное, что можно отметить в плюс - это ДТД.
> а если клиент хочет что либо поменять после принятия - этот вопрос решается деньгами, новым ТЗ и т.д.ничего не теряю....
я, надеюсь, ты понимаешь, что ты на этом теряешь что-то важное?
приобретаю нового клиента и прибыль...
Сколько кода надо будет переписать, если к тебе придет дизайнер и скажет, что теперь меню слева, а не сверху?Полстранички, не больше... Табличная верстка никогда еще не подводила.
Даже если у тебя тысяча таблиц?Не представляю себе, где такая структура может найти применение. У меня сейчас на крупном портале вся база - полсотни таблиц на всё про всё. Если их соптимизировать, то можно ужать до полутора-двух десятков
закодить html в 1000 страниц имхо сложнее, чем 1 страницу xsltА закодить одну страницу PHP имхо гораздо проще, чем ее же в xslt
ERP-система, например.
У меня сейчас на крупном портале вся база - полсотни таблиц на всё про всё. Если их соптимизировать, то можно ужать до полутора-двух десятковПоясни, плз, что ты тут имеешь ввиду под словом "соптимизировать"?
Упс, сорри, забыл поставить галку "оффтопик"
а GHU система не подходит?
> Полстранички, не больше... Табличная верстка никогда еще не подводила.
приведи, пожалуйста, пример - хотя бы для этой страницы форума.
приведи, пожалуйста, пример - хотя бы для этой страницы форума.
> а GHU система не подходит?
Что такое GHU?
ps
я правильно понял, что ты поленился посмотреть, что такое erp-системы в yandex-е?
Что такое GHU?
ps
я правильно понял, что ты поленился посмотреть, что такое erp-системы в yandex-е?
Хм... скажем так... допустим, есть у нас две ленты новостей - пусть 1 и 2. Для каждой - своя таблица. Если добавить одно поле в одну таблицу, то количество таблиц, нужных для описания новостей, уменьшится вдвое. Это самый последний пример.
а разве нельзя все данные держать, вообще, в одной таблице?
правильно...
А ты пошел искать GHU...
Просто дело в том, что кроме аббривеатуры полезно риводить и какие никакие ссылки, а не посылать человека непойми куда... И то сразу три буквы вспоминаются: [eq
А ты пошел искать GHU...
Просто дело в том, что кроме аббривеатуры полезно риводить и какие никакие ссылки, а не посылать человека непойми куда... И то сразу три буквы вспоминаются: [eq
О! это уже лучше.закодить html в 1000 страниц имхо сложнее, чем 1 страницу xsltА закодить одну страницу PHP имхо гораздо проще, чем ее же в xslt
к стати, еще немного, в пользу XSLt
все же XSLT как-бы предназначен для работы с XML, т.е. с полуструктурированными данными, то есть те решения, которые изначально разработаны при использовании реляционных данных и не должны вовсе с XSLT работать быстрее, чем со стандартными средствами.
Так вот, такой вопрос:
такая задача:
есть сервер с XML базой.
мы к нему задаем запрос, ну путь XQuery
и получаем ответ --- пусть XML документ, в котором он нашел соответствие запросу.
Необходимо вывести на страницу этот XML докумен (пусть он небольшой, вершин 100)
в виде дерева, в естественном его виде.
//дерево, таким образом, как сделан вывод дерева сообщений в форуме.
Что будет проще написать:
преобразование XML документа на PHP
или
преобразование на XSLT ?
Ну, это надуманный пример, я бы сказал.
Хотя и не исключено его возникновение в практике, чаще, по-моему, количество таблиц только возрастает со временем. Например, при нормализации. Соб-сно, мне поэтому и показалось странным, что ты уменьшаешь количество таблиц, а не увеличиваешь.
Хотя и не исключено его возникновение в практике, чаще, по-моему, количество таблиц только возрастает со временем. Например, при нормализации. Соб-сно, мне поэтому и показалось странным, что ты уменьшаешь количество таблиц, а не увеличиваешь.
Тебе минус, если ты не видишь очевидные недостатки xslt:по 2ому
1. сложность обучения кодера (что проще, найти кодера на html или xslt?)
2. медленность работы
возьми какой нить шаблонизатор и выведи таблицу на 60000 строк с помощью него
и с помощью XSLT
и посмотри кто быстрее.
Необходимо вывести на страницу этот XML докумен (пусть он небольшой, вершин 100)проще выдать как есть...
в виде дерева, в естественном его виде.
//дерево, таким образом, как сделан вывод дерева сообщений в форуме.
Что будет проще написать:
преобразование XML документа на PHP
или
преобразование на XSLT ?
поменяв заголовки на xhtml и добавить CSS
> Просто дело в том, что кроме аббривеатуры полезно риводить и какие никакие ссылки,
так ты все-таки попробуй в yandex-е набрать ERP и система
ps
аббревиатура ERP - такая же известная аббревиатура, как и используемые в данном треде аббревиатуры XML, HTML, PHP и т.д.
так ты все-таки попробуй в yandex-е набрать ERP и система
ps
аббревиатура ERP - такая же известная аббревиатура, как и используемые в данном треде аббревиатуры XML, HTML, PHP и т.д.
думаю, что разницы ты не заметишь из-за проблем с выводом в режиме реал-тайм большого объема информации у браузеров...
ЗЫ выведи просто 60000 раз слово "ура", и посмотри время серверной обработки и срамя вывода браузером...
ЗЫ выведи просто 60000 раз слово "ура", и посмотри время серверной обработки и срамя вывода браузером...
х.з.
смотрел сам, года два назад.
1000 XML документов.
довольно простой шаблон XSLT
т.к. работало медленнно, шаблон был очень простым, а документы имели тоже довольно простой и однообразный формат, написал на c++,
который его безбожно уделывал ( в 10-30 раз быстрее)
конечно, все зависит от задачи, если бы шаблоны были сильно сложные, хотябы использовали оси и т.п., то малой кровью я бы не отделался.
смотрел сам, года два назад.
1000 XML документов.
довольно простой шаблон XSLT
т.к. работало медленнно, шаблон был очень простым, а документы имели тоже довольно простой и однообразный формат, написал на c++,
который его безбожно уделывал ( в 10-30 раз быстрее)
конечно, все зависит от задачи, если бы шаблоны были сильно сложные, хотябы использовали оси и т.п., то малой кровью я бы не отделался.
> Просто дело в том, что кроме аббривеатуры полезно риводить и какие никакие ссылки,нет, так а где там про 1000 таблиц?
так ты все-таки попробуй в yandex-е набрать ERP и система
да, таблиц много, это и ежу понятно, но цифра 1000 у тебя из головы взята.....
в файл вывод загнать не так уж сложно.
а зачем нам вывод в файл применительно к вебу?
(при динамической генерции)
(при динамической генерции)
http://www.axforum.ru/forums/showthread.php?postid=16940
Большое спасибо, Mazzy. После синхронизации и в самом деле демка без проблем встала. И количество таблиц стало 1586 .
а как
добавить оформление, ссылки перехода на страницы?
// кстати, а что дает изменение расширения на xhtml ?
// ща почитаю в инете, если лень писать.
добавить оформление, ссылки перехода на страницы?
// кстати, а что дает изменение расширения на xhtml ?
// ща почитаю в инете, если лень писать.
Что будет проще написать:XML распарсить можно expat'ом, например. Быстро и надежно.
преобразование XML документа на PHP
или
преобразование на XSLT ?
Сгенерировать ответ -- любым шаблонизатором. Обходчик по дереву разве сложно написать и получить массив?
для сравнения скорости.
все равно преобразования XSlT происходят на стороне сервера(и выводятся в файл а потом уже кочуют к клиену в виде html. (или я ошибаюсь?)
так что скорость важна, по понятным причинам.
все равно преобразования XSlT происходят на стороне сервера(и выводятся в файл а потом уже кочуют к клиену в виде html. (или я ошибаюсь?)
так что скорость важна, по понятным причинам.
> кстати, а что дает изменение расширения на xhtml ?
ничего не дает, только специфицирует, что файл должен кроме правил html-я должен удовлетворять и правилам xml-я
ничего не дает, только специфицирует, что файл должен кроме правил html-я должен удовлетворять и правилам xml-я
и вообще - по моему - это бредовые аргументы, когда кидаешься в крайности, которые встречаются донельзя редко....
типа, а вот у меня вообще-то все работает херово, но если взять гипотетическую ситуацию, то мой продукт удеоает все ваши....
Ну и пусть уделывает... наши рассчитаны на конкретные области рименения, а твой гипотетический - просто так, выебон....
К примеру - нахера ставить жаропрочные пластины от шатла на обшивку легковушки?
абсурдно? вот и ваши аргументы про 1000 таблиц, 60000 записей в выводе таблицы.... это ЧАСТНЫЕ случаи, а мы говроим об общих...
типа, а вот у меня вообще-то все работает херово, но если взять гипотетическую ситуацию, то мой продукт удеоает все ваши....
Ну и пусть уделывает... наши рассчитаны на конкретные области рименения, а твой гипотетический - просто так, выебон....
К примеру - нахера ставить жаропрочные пластины от шатла на обшивку легковушки?
абсурдно? вот и ваши аргументы про 1000 таблиц, 60000 записей в выводе таблицы.... это ЧАСТНЫЕ случаи, а мы говроим об общих...
Сейчас бывают даже компилирующие XSLT-процессоры - они компилуют XSLT в исполняемый код (ну или псевдоисполняемый - Java bytecode, CIL). Они наверняка работают быстрее, чем обычные интерпретирующие 2 года назад!
> диаграммке костяка страницы - что вот слева у нас меню, в центре - данные,
> снизу выбранный элемент и т.д.
Если набор представленных данных (контент) при этом не меняется, то нужно изменить лишь шаблон. Разве в случае XSLT это как-то иначе делается?
> снизу выбранный элемент и т.д.
Если набор представленных данных (контент) при этом не меняется, то нужно изменить лишь шаблон. Разве в случае XSLT это как-то иначе делается?
> вот и ваши аргументы про 1000 таблиц, 60000 записей в выводе таблицы.... это ЧАСТНЫЕ случаи, а мы говроим об общих...
Это не частный случай - это просто другой сегмент рынка, на котором совсем другие запросы, и крутятся совсем другие деньги.
зы
я правильно понял, что ты так и собираешься всю жизнь клепать на коленке тырчики (мопеды а шаттлы так и останутся для тебя чем-то таким далеким.
Это не частный случай - это просто другой сегмент рынка, на котором совсем другие запросы, и крутятся совсем другие деньги.
зы
я правильно понял, что ты так и собираешься всю жизнь клепать на коленке тырчики (мопеды а шаттлы так и останутся для тебя чем-то таким далеким.
XML распарсить можно expat'ом, например. Быстро и надежно.на счет быстротысразу вопрос: у них(expat-а) есть сравнения скорости с XSLT? (если да, то интересно было бы посмотреть)
Сгенерировать ответ -- любым шаблонизатором. Обходчик по дереву разве сложно написать и получить массив?Да все это не сложно сделать, но лично для меня для решения этой задачи необходимо написать несколько строк XSLT кода.
конечно, что сложнее сделать - вопрос конкретного программиста, но кода на XSLT получится меньше.
я правильно понял, что ты так и собираешься всю жизнь клепать на коленке тырчики (мопеды а шаттлы так и останутся для тебя чем-то таким далеким.нет, неправильно..
хотел сказать, что для каждой модели прежде чем их сравнивать надо четко указать рамки ее применения...
и если рамки и условия разные, то как может идти речь о сравнении?
Как можно сравнивать теплое с мягким ?
на счет быстротысразу вопрос: у них(expat-а) есть сравнения скорости с XSLT? (если да, то интересно было бы посмотреть)а тебе не кажется, что скорость будет заметно зависить от степени интегрированности...
И если одна часть интегрирована, а другая - надстройка - разность в скорости очевидна....
+1.
давайте определимся с областями применения
и с тем, что между собою сравниваем. а то не очень конструктивно получается.
давайте определимся с областями применения
и с тем, что между собою сравниваем. а то не очень конструктивно получается.
вот и ваши аргументы про 1000 таблиц, 60000 записей в выводе таблицы.... это ЧАСТНЫЕ случаи, а мы говроим об общих...да ты проверь на своем любимом пхп со своими шаблонами или с каким другим. и сравни кто быстрее.
> Если набор представленных данных (контент) при этом не меняется, то нужно изменить лишь шаблон.
упрощаешь ситуацию, уходя от примера.
когда все перемешано - надо сначала в уме разобрать весь шаблон на составляющие (расскраска, поддержка браузеров и т.д потом поменять только нужную часть, потом собрать все обратно.
Причем смотря в код - программист не видит - что вот этот if отвечает за раскраску, этот вот if - за поддержку браузера Xzu, а вот этот if - если в браузере отключены cookies, а вот этот if - это тот самый if - который и отвечает где у нас будет меню слева или сверху.
> Разве в случае XSLT это как-то иначе делается?
XSLT-технология - это одна из технологий, которая мне позволяет разнести формирование представления по нескольким уровням (формирования костяка, учет пожеланий пользователя, учет браузера, расскраска).
Предложенный тобой шаблонизатор - это делать не умеет, и требует чтобы все было навалено в кучу.
упрощаешь ситуацию, уходя от примера.
когда все перемешано - надо сначала в уме разобрать весь шаблон на составляющие (расскраска, поддержка браузеров и т.д потом поменять только нужную часть, потом собрать все обратно.
Причем смотря в код - программист не видит - что вот этот if отвечает за раскраску, этот вот if - за поддержку браузера Xzu, а вот этот if - если в браузере отключены cookies, а вот этот if - это тот самый if - который и отвечает где у нас будет меню слева или сверху.
> Разве в случае XSLT это как-то иначе делается?
XSLT-технология - это одна из технологий, которая мне позволяет разнести формирование представления по нескольким уровням (формирования костяка, учет пожеланий пользователя, учет браузера, расскраска).
Предложенный тобой шаблонизатор - это делать не умеет, и требует чтобы все было навалено в кучу.
В ответ на:
ничего не теряю....
приобретаю нового клиента и прибыль...
ты правда чтоли не понимаешь?
> хотел сказать, что для каждой модели прежде чем их сравнивать надо четко указать рамки ее применения...
> и если рамки и условия разные, то как может идти речь о сравнении?
Речь идет о больших проектах: web-магазины (Amazon, Ozon и т.д. системы учета и управления (ERP-и, CRM-ы и т.д.)
т.к именно на больших задачах видно разницу - сколько времени реально затрачивается на разработку каждой страницы проекта.
на маленьких проектах - все будет упираться в человеческий фактор.
> и если рамки и условия разные, то как может идти речь о сравнении?
Речь идет о больших проектах: web-магазины (Amazon, Ozon и т.д. системы учета и управления (ERP-и, CRM-ы и т.д.)
т.к именно на больших задачах видно разницу - сколько времени реально затрачивается на разработку каждой страницы проекта.
на маленьких проектах - все будет упираться в человеческий фактор.
> XSLT-технология - это одна из технологий, которая мне позволяет разнести
> формирование представления по нескольким уровням
Это нормально для языка программирования (гугл говорит, что xslt is turing complete).
> Предложенный тобой шаблонизатор - это делать не умеет, и требует чтобы все было навалено в кучу.
Потому что это более специальный случай, не включающий в себя полноценный язык (в качестве такового нужно использовать perl).
Вот задача и сводится к тому, писать всё на одном языке (xslt или всё-таки иногда нужны и другие.
> формирование представления по нескольким уровням
Это нормально для языка программирования (гугл говорит, что xslt is turing complete).
> Предложенный тобой шаблонизатор - это делать не умеет, и требует чтобы все было навалено в кучу.
Потому что это более специальный случай, не включающий в себя полноценный язык (в качестве такового нужно использовать perl).
Вот задача и сводится к тому, писать всё на одном языке (xslt или всё-таки иногда нужны и другие.
> и если рамки и условия разные, то как может идти речь о сравнении?Ну вот, а я говорил наоборот о маленьких неспециализированных а общих проектах как то представительские и корпоративные сайты, муз-каталоги, форумы, вебмагазинах...
Речь идет о больших проектах: web-магазины (Amazon, Ozon и т.д. системы учета и управления (ERP-и, CRM-ы и т.д.)
Кстати, вебмагазины - не такие там и большие роблемы с шаблонами... так то в рязряд с ЕПР их ставить не надо
2 Скиф - правда чтоли не понимаешь?
нет, но зачем же смеятся - объясни?
> Вот задача и сводится к тому, писать всё на одном языке (xslt или всё-таки иногда нужны и другие
Вопрос в сторону: можно ли говорить - что одни языки более универсальны, удобны, эффективны и т.д. на более широком круге задач, чем другие?
Вопрос в сторону: можно ли говорить - что одни языки более универсальны, удобны, эффективны и т.д. на более широком круге задач, чем другие?
Можно, тут регулярно такое говорят. 
> в качестве такового нужно использовать perl
почему не asm?
почему не asm?
скорее уж эффективны в более узкой области.....
> (в качестве такового нужно использовать perl
ты можешь аргументировано показать, что твой выбор perl-а для данной задачи был сознательным, а не просто копированием поведения остального миллиона мух и леммингов?
ты можешь аргументировано показать, что твой выбор perl-а для данной задачи был сознательным, а не просто копированием поведения остального миллиона мух и леммингов?
я не выбирал ничего, просто пример привёл
т.е. у тебя нет своего мнения как лучше решать данную задачу?
т.е. у тебя нет своего подхода (своей системы критериев) - который бы позволял сказать - что вот это решение лучше подходит для решения данной задачи, а это - хуже?
т.е. у тебя нет своего подхода (своей системы критериев) - который бы позволял сказать - что вот это решение лучше подходит для решения данной задачи, а это - хуже?
это довольно далеко от того, чем я обычно занимаюсь
Можно ли сказать, что данная задача, а также твои задачи подходят под следующую модель:
есть изменяющиеся требования внешнего мира
есть система (код) - который меняться в след за изменениями требований внешнего мира.
внешний мир - это все-то чем мы не можем управлять напрямую, или можем но плохо и дорого.
можно ли (и какие) для этой модели выдвинуть критерии, который позволяют оценить и сравнить между собой тот или иной подход?
есть изменяющиеся требования внешнего мира
есть система (код) - который меняться в след за изменениями требований внешнего мира.
внешний мир - это все-то чем мы не можем управлять напрямую, или можем но плохо и дорого.
можно ли (и какие) для этой модели выдвинуть критерии, который позволяют оценить и сравнить между собой тот или иной подход?
т.е. это один из примеров, который описывает подход к решению...
И для конечного пользователя, который не является профессионалом в данной области он не лучше и не хуже других....
а значит, что и споры наши бесполезны...
Ибо конечного пользователя интересует только конечный результат, а не дорога сквозь тернии программиста...
И для конечного пользователя, который не является профессионалом в данной области он не лучше и не хуже других....
а значит, что и споры наши бесполезны...
Ибо конечного пользователя интересует только конечный результат, а не дорога сквозь тернии программиста...
> Ибо конечного пользователя интересует только конечный результат, а не дорога сквозь тернии программиста...
конечный результат характеризуют такие параметры, как скорость, стоимость и качество.
Все эти три показателя - очень сильно зависит от того, какой подход выбрал программист.
конечный результат характеризуют такие параметры, как скорость, стоимость и качество.
Все эти три показателя - очень сильно зависит от того, какой подход выбрал программист.
а выбор подхода в свою очередь зависит от требований, предъявлемых к системе...
XLST:1) XSLT - технология. Технология не может быть быстрой или медленной. Медленным может быть процессор. Возможно, ты используешь медленный процессор?
1) медленный
2) сложный для кодирования (заметь, уже не "кодер" в Яндексе, а прогламмист! )
3) не имеет никаких преимуществ перед другими шаблонизаторами
2) Сложный? на мой взгляд, научиться пользоваться html сложнее. Поясню, в каком смысле. Писать код, который более менее одинаково выглядит во всех браузерах - это не просто (надо знать, что существует браузер и что он не один
). Чтобы освоить xslt, не надо знать, что такое браузер, что их бывает много и всякую другую ерунду. Если человек не может освоить xslt, то, имхо, делать реально качественный html тоже не сможет.3) ну да. мясорубка не имеет никаких преимуществ перед другими газонокосилками.
Если человек не может освоить xslt, то, имхо, делать реально качественный html тоже не сможетВ этом утверждении отсутствует логика...
Ибо не обязательно быть курицей, что бы разбираться в яйцах...
да, верно, логики нет. поэтому вставил имхо но вообще считаю, что это будет верно для большого процента людей.
но вообще считаю, что это будет верно для большого процента людей.+1
считаю, что научиться html нормально верстать гораздо сложнее, чем освоить xslt и соотв xml api
считаю, что научиться html нормально верстать гораздо сложнее, чем освоить xslt и соотв xml api
а херли тогда за html верстку платят раза в 2-3 меньше, чем за xslt?
Если бы все бало так просто - все бы давно уже забили на html
Если бы все бало так просто - все бы давно уже забили на html
потому, что предложение больше.
книжек по html много.
опыта разработки и использования, в конце концов.
xslt относительно новая технология.
книжек по html много.
опыта разработки и использования, в конце концов.
xslt относительно новая технология.
я наверно туплю, но как xslt расшифровывается?
Extensible Stylesheet Language for Transformations вроде
Я не знаю ни одной более-менее работающей реализации xslt. Скорее всего, ее не может быть в принципе, и это минус xslt.
Я думаю, что тему можно закрыть. Кому-то дано писать работающие программы, кому-то внедрять мегатехнологии.
Я думаю, что тему можно закрыть. Кому-то дано писать работающие программы, кому-то внедрять мегатехнологии.
и опять бред, как и любого рода столь категоричные утверждения.
скорость работы лишь один параметр из многих характеризующий полезность применения технологии в том или ином проекте.
да и вообще, можно сколько угодно кричать, что xslt говно
(что не так давно было, например с языком java)
но несмотря на это, у технологии есть свое применение и тем, кому она нужна, будут ее использовать.
а при вложении некоторого количества сил и средств, возможно настанет момент, когда скорость преобразования по xslt-шаблонам сравняется с уровнем самописных программ.
скорость работы лишь один параметр из многих характеризующий полезность применения технологии в том или ином проекте.
да и вообще, можно сколько угодно кричать, что xslt говно
(что не так давно было, например с языком java)
но несмотря на это, у технологии есть свое применение и тем, кому она нужна, будут ее использовать.
а при вложении некоторого количества сил и средств, возможно настанет момент, когда скорость преобразования по xslt-шаблонам сравняется с уровнем самописных программ.
Xalan-j, System.Xml.Xsl ?
> Я не знаю ни одной более-менее работающей реализации xslt. Скорее всего, ее не может быть в принципе, и это минус xslt.
Вот это LOL. Может карма у тебя такая, или руки кривые просто? Поверь, ничего личного, просто я вижу как XSLT в куче проектов нормально, успешно применяется (на самых разных XSLT-процессорах) и таких жалоб нет.
Вот это LOL. Может карма у тебя такая, или руки кривые просто? Поверь, ничего личного, просто я вижу как XSLT в куче проектов нормально, успешно применяется (на самых разных XSLT-процессорах) и таких жалоб нет.
а кстити было бы неплохо привести какой нить пример типа hello? world на xslt
<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<xsl:text>Hello, world!</xsl:text>
</xsl:template>
</xsl:stylesheet>
The XML page cannot be displayed
Cannot view XML input using style sheet. Please correct the error and then click the Refresh button, or try again later.
--------------------------------------------------------------------------------
Expecting whitespace or '?'. Error processing resource 'file:///C:/Documents and Settings/Administrator/Desktop/twst.xml'. Line 1, Position 20
<?xml version="1.0"/>
-------------------^
А рабочий ?
<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
вот за что я не люблю xml
за что именно?
не люблю языки, в которых обязателен длинный бессодержательный заголовок (или прочее оформление) даже для самых простых примеров
simple things should be easy, hard things should be possible
на втором месте в моём hatelist - java
simple things should be easy, hard things should be possible
на втором месте в моём hatelist - java
> не люблю языки, в которых обязателен длинный бессодержательный заголовок
так это он твой взгляд бессодержательный
а с точки зрения парсера - все эти слова жизненно-необходимы для корректного разбора и выполнения.
так это он твой взгляд бессодержательный
а с точки зрения парсера - все эти слова жизненно-необходимы для корректного разбора и выполнения.
// на втором месте в моём hatelist - java
Много ты с ним работал, можно полюбопытствовать? И что не понравилось?
Много ты с ним работал, можно полюбопытствовать? И что не понравилось?
> а с точки зрения парсера - все эти слова жизненно-необходимы
потому что xml предназначен для такого вот тупого парсера, а не для человека
в качестве промежуточного формата, в который лишь иногда (для отладки) приходится руками лезть, я не против xml
потому что xml предназначен для такого вот тупого парсера, а не для человека
в качестве промежуточного формата, в который лишь иногда (для отладки) приходится руками лезть, я не против xml
на самом деле можно и так:
но при этом в ряде случаев - можно огрести различные спец-эффекты.
ps
я правильно понял, что ты даже против правила - что имена функций и методов - должны называться полным именем?
<stylesheet>
<template match="/">
<text>Hello, world!</text>
</template>
</stylesheet>
но при этом в ряде случаев - можно огрести различные спец-эффекты.
ps
я правильно понял, что ты даже против правила - что имена функций и методов - должны называться полным именем?
<?xml version="1.0" ?>
- <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
- <xsl:template match="/">
<xsl:value-of select="Hello, world!" />
</xsl:template>
</xsl:stylesheet>
Это так и должно показываться?
Я просил просто вывод HelloWorld БЕЗ всяких левых тегов....
> на самом деле можно и так
уже лучше
но когда я пробовал работать с xml - нельзя было без заголовка
возможно, мне неправильные тулзы достались, и теперь всё лучше
> я правильно понял, что ты даже против правила - что имена функций и
> методов - должны называться полным именем?
Если это имя не помещается 3 раза в стандартную строчку, как обычно бывает в Java - то против.
уже лучше
но когда я пробовал работать с xml - нельзя было без заголовка
возможно, мне неправильные тулзы достались, и теперь всё лучше
> я правильно понял, что ты даже против правила - что имена функций и
> методов - должны называться полным именем?
Если это имя не помещается 3 раза в стандартную строчку, как обычно бывает в Java - то против.
recopy & reload
> Много ты с ним работал, можно полюбопытствовать?
Полгода примерно, может больше. Давно это было.
> И что не понравилось?
Честно говоря, не понравилось ничего.
Полгода примерно, может больше. Давно это было.
> И что не понравилось?
Честно говоря, не понравилось ничего.
<?xml version="1.0"?>
Hello, world!
а где XSLT?
на входе преобразователя
невижу....
вот как на html написать - вижу, а на xslt - невижу....
вот как на html написать - вижу, а на xslt - невижу....
> Я просил просто вывод HelloWorld БЕЗ всяких левых тегов....
возьми интерпретатор или компилятор xsl-я и запусти данный код
возьми интерпретатор или компилятор xsl-я и запусти данный код
возьми интерпретатор или компилятор xsl-я и запусти данный кода тогда не вижу преимушщества в простоте перед html, которое заявлено на редыдущей странице...
<xsl:output method="text"/>
ты правда такой тупой, или ты тут всех троллишь?
что-то я со счёта сбился
четвёртая уже попытка?
четвёртая уже попытка?
Если не ошибаюсь, XSLT - функция, которая имеет один обязательный аргумент.
Поэтому, чтобы это запустить, на вход нужно обязательно подать валидный XML
(по крайней мере у меня xsltproc ругается на пустой вход).
Поэтому, чтобы это запустить, на вход нужно обязательно подать валидный XML
(по крайней мере у меня xsltproc ругается на пустой вход).
хз, что ты имел ввиду под словом
ЗЫ И хватит писать по строчке...
Постите сюда готовый файл и успокоимся...
троллишь, но я пытаюсь выйдить из оппонентов не только голословные утверждения, но и доказательства...
ЗЫ И хватит писать по строчке...
Постите сюда готовый файл и успокоимся...
> Если не ошибаюсь, XSLT - функция, которая имеет один обязательный аргумент.
в какой-то мере - да, также как и sql - это тоже функция, для выполнения которого нужна предварительно заполненная база.
в какой-то мере - да, также как и sql - это тоже функция, для выполнения которого нужна предварительно заполненная база.
это если тебя раздражает <?xml...?> в начале результата
>> Если не ошибаюсь, XSLT - функция, которая имеет один обязательный аргумент.
> в какой-то мере - да,
Получается, что решение в любом случае будет некорректно, если подходить строго:
требуется программа, выдающая константу - функция арности 0,
а на XSLT можно сделать только функцию арности 1, возвращающую константу, не зависящую от входа.
> также как и sql - это тоже функция, для выполнения которого нужна предварительно заполненная база.
Не совсем так же.
В SQL можно написать SELECT "Hello World"; и SELECT "Hello World" from table;.
> в какой-то мере - да,
Получается, что решение в любом случае будет некорректно, если подходить строго:
требуется программа, выдающая константу - функция арности 0,
а на XSLT можно сделать только функцию арности 1, возвращающую константу, не зависящую от входа.
> также как и sql - это тоже функция, для выполнения которого нужна предварительно заполненная база.
Не совсем так же.
В SQL можно написать SELECT "Hello World"; и SELECT "Hello World" from table;.
> Если не ошибаюсь, XSLT - функция, которая имеет один обязательный
> аргумент.
> Поэтому, чтобы это запустить, на вход нужно обязательно подать валидный XML
Упс, а как тогда собираются использовать XSLT для унификации запросов к БД, к файлам разных форматов, к структурам любимого языка программирования?
> аргумент.
> Поэтому, чтобы это запустить, на вход нужно обязательно подать валидный XML
Упс, а как тогда собираются использовать XSLT для унификации запросов к БД, к файлам разных форматов, к структурам любимого языка программирования?
> Упс, а как тогда собираются использовать XSLT для унификации запросов к БД,
> к файлам разных форматов, к структурам любимого языка программирования?
Ну если есть, к чему запросы делать, то в чём проблема?
> к файлам разных форматов, к структурам любимого языка программирования?
Ну если есть, к чему запросы делать, то в чём проблема?
А можно какой-нибудь пример, типа как тот же /raw/posts.gz преобразовать в html? gunzip внешний, так уж и быть. Насколько это удобно будет?
Т. е. проблема в том, что ты не знаешь сегодняшнюю Java?
Следуя той же логике, все компы - дерьмо, потому что когда-то тебя задолбало совать в них перфокарты?
Следуя той же логике, все компы - дерьмо, потому что когда-то тебя задолбало совать в них перфокарты?
> Т. е. проблема в том, что ты не знаешь сегодняшнюю Java?
Там появилась нормальная система типов? Generics наконец-то добавили, но конструкторов и, наоборот, средств для декомпозиции алгебраических типов до сих пор нет.
Там уже не надо писать всё по три раза, всё по три раза, всё по три раза?
Компилятор уже дружит с make?
Там появилась нормальная система типов? Generics наконец-то добавили, но конструкторов и, наоборот, средств для декомпозиции алгебраических типов до сих пор нет.
Там уже не надо писать всё по три раза, всё по три раза, всё по три раза?
Компилятор уже дружит с make?
Ответ всем маразматикам, любителям использовать персональный атомный реактов в качестве чайника:
Пишите свои говнопроекты по обслуживанию 5 пользователей на 10 мегасерверах на: JAVA, XSLT. Отъебитесь только со своей говноаргументацией.
Если человек не понимает, что замена 100 серверов на 5 -- это не только успех в экономии денег, а еще экономия на их обслуживании, то это диагноз. Диагноз болезни, которая не лечится.
Пишите свои говнопроекты по обслуживанию 5 пользователей на 10 мегасерверах на: JAVA, XSLT. Отъебитесь только со своей говноаргументацией.
Если человек не понимает, что замена 100 серверов на 5 -- это не только успех в экономии денег, а еще экономия на их обслуживании, то это диагноз. Диагноз болезни, которая не лечится.
на вход xslt - можно подавать произвольную сущность, поддерживающую интерфейс IXPathNavigable,
валидный xml является одним из представителей, имеющих реализацию IXPathNavigable-а.
валидный xml является одним из представителей, имеющих реализацию IXPathNavigable-а.
как формат файла может поддерживать интерфейс?
> как формат файла может поддерживать интерфейс?
simple things should be easy, hard things should be possible
компьютер магическим способом догадывается, что у него оказывается есть реализация IXpathNavigable для данного формата файла и компьютер сам предоставляет данную реализацию xslt-движку.
simple things should be easy, hard things should be possible
компьютер магическим способом догадывается, что у него оказывается есть реализация IXpathNavigable для данного формата файла и компьютер сам предоставляет данную реализацию xslt-движку.
это на каком языке программирования нужно реализовывать интерфейс?
На том, который сможет понять твоя реализация xslt-движка.
IXPathNavigable - это кто придумал? w3c?
Получается, что чтобы доступаться к чему-то, нужно специальный интерфейс для сопряжения сначала реализовать. Что помешает и трансформацию на том же языке сделать, кроме возможной ущербности оного?
Получается, что чтобы доступаться к чему-то, нужно специальный интерфейс для сопряжения сначала реализовать. Что помешает и трансформацию на том же языке сделать, кроме возможной ущербности оного?
> Что помешает и трансформацию на том же языке сделать, кроме возможной ущербности оного?
то, что ты лишаешься reusing-а, т.к. часть трансформации в xslt-е виде уже может кем-то быть написано.
то, что ты лишаешься reusing-а, т.к. часть трансформации в xslt-е виде уже может кем-то быть написано.
> то, что ты лишаешься reusing-а, т.к. часть трансформации в xslt-е виде уже
> может кем-то быть написано.
а если оно написано не в xslt-виде, а в каком-то другом?
понятно, что если часть кода уже написана на каком-то языке, то это автоматически повышает применимость языка в данном проекте
а вот если у тебя все наработки, скажем, на perl - зачем вводить в проект xslt?
> может кем-то быть написано.
а если оно написано не в xslt-виде, а в каком-то другом?
понятно, что если часть кода уже написана на каком-то языке, то это автоматически повышает применимость языка в данном проекте
а вот если у тебя все наработки, скажем, на perl - зачем вводить в проект xslt?
тем, что xslt - более высокоуровневый, и лучше подходит для обработки структурированных документов
в чём это выражается?
да, поверх xslt можно построить двунаправленную-надстройку - с перлом все будет намного геморрнее в этом плане.
опять же xslt-преобразование можно автоматизированно попытаться проверить на правильность, с perl-ом опять все будет сложнее.
опять же xslt-преобразование можно автоматизированно попытаться проверить на правильность, с perl-ом опять все будет сложнее.
вот, помнится, при мне народ извращался
тогда это дело только придумали
надо было xml преобразовать в html в виде таблички - строчка тёмная, строчка светлая, чередование такое, как в этом форуме
упражнение такое было, кажется
код был не особо понятный
тогда это дело только придумали
надо было xml преобразовать в html в виде таблички - строчка тёмная, строчка светлая, чередование такое, как в этом форуме
упражнение такое было, кажется
код был не особо понятный
> в чём это выражается?
например, в том - что поддерживается единообразный мощный язык - для доступа к элементам этого структурированного документа
например, в том - что поддерживается единообразный мощный язык - для доступа к элементам этого структурированного документа
> например, в том - что поддерживается единообразный мощный язык - для
> доступа к элементам этого структурированного документа
в любом нормальном языке программирования нетрудно доступаться к данным с такой структурой
ведь xml - это всего лишь такой странноватый синтаксис для записи S-выражений, которые ещё в 60-е придумали\
соотвественно, любой язык с хорошей поддержкой алгебраических типов зарулит
> доступа к элементам этого структурированного документа
в любом нормальном языке программирования нетрудно доступаться к данным с такой структурой
ведь xml - это всего лишь такой странноватый синтаксис для записи S-выражений, которые ещё в 60-е придумали\
соотвественно, любой язык с хорошей поддержкой алгебраических типов зарулит
2 : Мне даже как-то и возразить тебе нечего Чувствуется, ты - в теме.
Чувствуется, ты - в теме.текущие алгебраические языки обычно не поддерживают хождение по осям, в отличие от XPath-а
И вот вместо того, чтоб взять нормальный язык, и добавить туда оси синтаксическим сахаром, придумали новый язык, в котором оси есть, и шаблоны есть, а вот с простыми вещами - слабовато.
В результате: для специализированных нужд сгодится, может быть, а в качестве унифицированного средства доступа к данным и их преобразования - уж извиняйте.
В результате: для специализированных нужд сгодится, может быть, а в качестве унифицированного средства доступа к данным и их преобразования - уж извиняйте.
А сколько серверов там где ты программируешь? Ты же на PHP я так понимаю программируешь?
а тогда не вижу преимушщества в простоте перед htmlhtml - это не язык программирования. Вот такое вот преимущество xslt перед html
Extensible Stylesheet Language for Transformations
Ты наверно хотел сказать расширяемый стилевой язык для трансформаций ?
Ты наверно хотел сказать расширяемый стилевой язык для трансформаций ?
Если бы ты потратил немножко времени на изучение XSLT, ты бы понял, что XSLT - именно язык программирования - в отличие от HTML. Функциональный, насколько я понимаю.
Я потратил вчера вечером немножко времени на изучение xslt. Но я не думаю что наличие конструкции if match делает его языком программирования.
потрать ещё немного времени
А все... Кончилась глава в книжке... :'-(
Рекурсия есть, переменные есть, функции, принимающие нужное число параметров - тоже есть. Средства для code reuse есть. Что ещё нужно? Даже IF и циклы есть...
Да это все неважно. В SQL вот нету ни циклов ни рекурсии, но никто не сомневается что это язык программирования, просто он не алгоритмически полный (XSLT кстати алгоритмически полный!) Просто чтобы быть языком программирования, нужно хотя бы иметь домен, то есть конструктивное описания множества данных, над которыми программы этого языка могут работать. Для SQL это база данных, для XSLT - XML документы. А у HTML нету никакого домена. Вот JavaScript - это язык программирования...
А css - это язык программирования?
Не понятно, а что является результатом работы css программы? Картинка в браузере что ли?
Визуальное представление документа, наверное
Ну вот и я о том же. Как ты потом это "Визуальное представление документа" в другую программу скажем передашь для дальнейшай обработки? А раз нельзя в другую программу передать, значит это не данные, по-моему так (С)
Но если Что-то не является Языком Программирования, это же не значит что Оно какое-то ущербное, Оно просто другое. Например, Оно может быть просто Языком Ну что, пофилософствуем?
Но если Что-то не является Языком Программирования, это же не значит что Оно какое-то ущербное, Оно просто другое. Например, Оно может быть просто Языком
Ну что, пофилософствуем? А я и не говорил что xslt ущербен.
p.s. Кстати sql я тоже считаю не языком программирования, а языком запросов
p.s. Кстати sql я тоже считаю не языком программирования, а языком запросов
> И вот вместо того, чтоб взять нормальный язык, и добавить туда оси синтаксическим сахаром, придумали новый язык, в котором оси есть, и шаблоны есть, а вот с простыми вещами - слабовато.
Xslt- это первый блин. Первый язык с осями, с унифицированным синтаксисом запросов и т.д.
И как я уже говорил - основной восторг вызывает не сам XSLT, а его подчасть - XPath.
И вот над этим XPath-ом, начинают, строить другие языки - XQuery, этот XPath - внедряют в стандартные(mainstream) языки - C(омега) и т.д.
и именно XPath и является одним из кирпичиков в построении унифицированного доступа к данным.
Xslt- это первый блин. Первый язык с осями, с унифицированным синтаксисом запросов и т.д.
И как я уже говорил - основной восторг вызывает не сам XSLT, а его подчасть - XPath.
И вот над этим XPath-ом, начинают, строить другие языки - XQuery, этот XPath - внедряют в стандартные(mainstream) языки - C(омега) и т.д.
и именно XPath и является одним из кирпичиков в построении унифицированного доступа к данным.
> Xslt- это первый блин. Первый язык с осями, с унифицированным
> синтаксисом запросов и т.д.
Круто, но зачем стулья-то ломать (выкидывать возможности "настоящих" языков)? Можно было изобрести XML-синтаксис для Лиспа (теги вместо скобочек, раз уж их так не любят и язык бы вышел нормальный, с возможностью использовать привычный синтаксис для знающих Лисп. Оси и xpath-запросы делаются библиотечными функциями/макросами.
> этот XPath - внедряют в стандартные(mainstream) языки - C(омега) и т.д.
Ну а с этим, естественно, проблема сопряжений системы типов возникает. Такой гибрид тоже не пригоден на роль "лучшего языка запросов к любым данным". Выигрывают от такого лишь пресловутые индусы, которым платят "построчно".
> синтаксисом запросов и т.д.
Круто, но зачем стулья-то ломать (выкидывать возможности "настоящих" языков)? Можно было изобрести XML-синтаксис для Лиспа (теги вместо скобочек, раз уж их так не любят и язык бы вышел нормальный, с возможностью использовать привычный синтаксис для знающих Лисп. Оси и xpath-запросы делаются библиотечными функциями/макросами.
> этот XPath - внедряют в стандартные(mainstream) языки - C(омега) и т.д.
Ну а с этим, естественно, проблема сопряжений системы типов возникает. Такой гибрид тоже не пригоден на роль "лучшего языка запросов к любым данным". Выигрывают от такого лишь пресловутые индусы, которым платят "построчно".
Community лисп-а такая мощная что ее нужно и стоит принимать во внимание?
> Ну а с этим, естественно, проблема сопряжений системы типов возникает.
Почему ты считаешь что она неразрешимая?
> Ну а с этим, естественно, проблема сопряжений системы типов возникает.
Почему ты считаешь что она неразрешимая?
> Community лисп-а такая мощная что ее нужно и стоит принимать во внимание?
Дело не в community, а в том, что это полновесный язык, удобный как раз для того же самого. Изобретая новый язык, можно было бы учесть опыт.
> Почему ты считаешь что она неразрешимая?
Разрешима, путём модификации системы типов языка. Если всё правильно сделать, получится Lisp (*ML или Haskell тоже может получиться, если сделать кое-что ещё).
Дело не в community, а в том, что это полновесный язык, удобный как раз для того же самого. Изобретая новый язык, можно было бы учесть опыт.
> Почему ты считаешь что она неразрешимая?
Разрешима, путём модификации системы типов языка. Если всё правильно сделать, получится Lisp
(*ML или Haskell тоже может получиться, если сделать кое-что ещё).Почему получится lisp? почему не asm?
почему ты считаешь именно Лисп - необходимым и достаточным базисом? по каким критериям?
или это опять же привычка и подражание остальному миллиону мух и леммингов?
да и почему ты asm, например, ты таким базисом не считаешь?
почему ты считаешь именно Лисп - необходимым и достаточным базисом? по каким критериям?
или это опять же привычка и подражание остальному миллиону мух и леммингов?
да и почему ты asm, например, ты таким базисом не считаешь?
Лисп - минимальный язык, имеющий как средства работы с деревьями (композиция и декомпозиция S-выражений так и возможность введения высокоуровневых абстракций. То есть это минимум, не включать который - некультурно.
Усовершенствования, конечно, возможны.
Усовершенствования, конечно, возможны.
в asm-е разве таких возможностей нет?
ps
ты упорно уходишь от выдвижения критериев, на основе который ты строишь свои обоснования.
фактически получается - что ты свои мысли - строишь как аксиомы...
ps
ты упорно уходишь от выдвижения критериев, на основе который ты строишь свои обоснования.
фактически получается - что ты свои мысли - строишь как аксиомы...
> в asm-е разве таких возможностей нет?
нет, конечно
если их туда добавить, какими-нибудь макросами - получится язык высокого уровня
нет, конечно
если их туда добавить, какими-нибудь макросами - получится язык высокого уровня
> если их туда добавить, какими-нибудь макросами - получится язык высокого уровня
но речь же шла о базисе, а не о том считать язык или не считать высокоуровневым
ps
Большая часть твоих аргументов - обычно сводятся: "а это я могу в лиспе как нефиг делать написать", т.е. получается, что Lisp+доп. библиотеки ты почему-то считаешь за лисп, а asm+доп. библиотеки - ты считаешь не за асм, а за более высокоуровневый язык.
Почему такая разница?
ззы
мне вот до сих пор интересно, почему ты считаешь разница между asm-ом и лиспом больше, чем разница между лиспом и например, C++?
но речь же шла о базисе, а не о том считать язык или не считать высокоуровневым
ps
Большая часть твоих аргументов - обычно сводятся: "а это я могу в лиспе как нефиг делать написать", т.е. получается, что Lisp+доп. библиотеки ты почему-то считаешь за лисп, а asm+доп. библиотеки - ты считаешь не за асм, а за более высокоуровневый язык.
Почему такая разница?
ззы
мне вот до сих пор интересно, почему ты считаешь разница между asm-ом и лиспом больше, чем разница между лиспом и например, C++?
Что входит в базис языка для обработки XML-подобных данных- я перечислил.
Никакая библиотека для asm или С не даст возможность написать что-то вроде
Вот это и есть проблема сопряжения: нету в языке ни встроенных средств декомпозиции и сравнения с шаблоном, ни макросов, чтоб ввести это.
Можно только внешним компилятором/препроцессором их ввести, сделав таким образом транслятор лиспоподобного языка.
Никакая библиотека для asm или С не даст возможность написать что-то вроде
match (xmldata) {
with <t>
<a p=$p>$a</a>
List(<b>$b</b>)
</t>: {
// в этом локальном контексте определены:
// XMLData a; // поддерево
// XMLAttr p; // значение атрибута
// XMLData b[]; // список поддеревьев
}
with ... : // другой шаблон
}
Вот это и есть проблема сопряжения: нету в языке ни встроенных средств декомпозиции и сравнения с шаблоном, ни макросов, чтоб ввести это.
Можно только внешним компилятором/препроцессором их ввести, сделав таким образом транслятор лиспоподобного языка.
почему то что сверху - Лисп?
а вот это не асм:
?
критерий есть?
а вот это не асм:
push eax, const "bla-bla"
call eval
?
критерий есть?
> вот это не асм
я такого не говорил
ты собрался преобразовывать XML на таком асме?
я такого не говорил
ты собрался преобразовывать XML на таком асме?
> ты собрался преобразовывать XML на таком асме?
хз, а почему бы и нет? смотря какие библиотеки подключены.
ты же так критерий и не привел - когда можно, а когда нельза на таком-то языке преобразовывать xml...
хз, а почему бы и нет? смотря какие библиотеки подключены.
ты же так критерий и не привел - когда можно, а когда нельза на таком-то языке преобразовывать xml...
> почему то что сверху - Лисп?
потому что на таком языке программировать обработку данных будет удобно, используя те приёмы, которые сейчас ассоциируются с лиспом
называть такой язык можно будет как угодно, но любой любитель лиспа почувствует там себя как дома
потому что на таком языке программировать обработку данных будет удобно, используя те приёмы, которые сейчас ассоциируются с лиспом
называть такой язык можно будет как угодно, но любой любитель лиспа почувствует там себя как дома
> называть такой язык можно будет как угодно, но любой любитель лиспа почувствует там себя как дома
почему он в асме будет не как дома?
критерий у тебя есть?
почему он в асме будет не как дома?
критерий у тебя есть?
> почему он в асме будет не как дома?
если в этом асме будут
* локальные переменные, с соответствующими областями видимости
* эти переменные смогут хранить поддокументы в XML
* средства декомпозиции таких данных, и композиции из поддокументов
* возможность определения функций (как следствие - замыканий и макросов (для того, чтоб шаблоны сколь угодно сложного вида вводить)
то только ты будешь продолжать называть это асмом, а программист с неким кругозором, и средне развитой способностью замечать подобия скажет, что это сильно похоже на лисп
> критерий у тебя есть?
смешно
был бы формальный критерий, можно было бы автоматически сгенерировать самый лучший язык и компилятор к нему
"вылядит, как утка, крякает как утка" и т.д. - только такого рода критерии возможны
если в этом асме будут
* локальные переменные, с соответствующими областями видимости
* эти переменные смогут хранить поддокументы в XML
* средства декомпозиции таких данных, и композиции из поддокументов
* возможность определения функций (как следствие - замыканий и макросов (для того, чтоб шаблоны сколь угодно сложного вида вводить)
то только ты будешь продолжать называть это асмом, а программист с неким кругозором, и средне развитой способностью замечать подобия скажет, что это сильно похоже на лисп
> критерий у тебя есть?
смешно
был бы формальный критерий, можно было бы автоматически сгенерировать самый лучший язык и компилятор к нему
"вылядит, как утка, крякает как утка" и т.д. - только такого рода критерии возможны
> был бы формальный критерий, можно было бы автоматически сгенерировать самый лучший язык и компилятор к нему
в честь чего это?
вон критерий в шахматы давно есть - лучшех всех играет тот, кто быстрее (или, например, чаще) остальных ставит мат.
слабо автоматически сгенерировать лучшего игрока в шахмтаты?
во-вторых: критерии часто бывают взаимопротивополжные - например, удобство и скорость выполнения.
тогда критерии фиксируются один раз: а баланс уже в большой степени подбирается исходя из задачи
> "вылядит, как утка, крякает как утка" и т.д. - только такого рода критерии возможны
и никаких более "независимых" критериев придумать нельзя?
объем кода? скорость внесения изменений? производительность? и т.д.?
в честь чего это?
вон критерий в шахматы давно есть - лучшех всех играет тот, кто быстрее (или, например, чаще) остальных ставит мат.
слабо автоматически сгенерировать лучшего игрока в шахмтаты?
во-вторых: критерии часто бывают взаимопротивополжные - например, удобство и скорость выполнения.
тогда критерии фиксируются один раз: а баланс уже в большой степени подбирается исходя из задачи
> "вылядит, как утка, крякает как утка" и т.д. - только такого рода критерии возможны
и никаких более "независимых" критериев придумать нельзя?
объем кода? скорость внесения изменений? производительность? и т.д.?
> и никаких более "независимых" критериев придумать нельзя?
> объем кода? скорость внесения изменений? производительность? и т.д.?
это не будет критерием принадлежности языка к данному семейству
связь удобства обработки древовидных данных и похожести на лисп - эмпирическая, и основана на неполной индукции
возможно, кто-то придумает более удобный/универсальный/и т.д. язык, основанный на другом базисе, но пока, насколько я знаю, такого не произошло
> объем кода? скорость внесения изменений? производительность? и т.д.?
это не будет критерием принадлежности языка к данному семейству
связь удобства обработки древовидных данных и похожести на лисп - эмпирическая, и основана на неполной индукции
возможно, кто-то придумает более удобный/универсальный/и т.д. язык, основанный на другом базисе, но пока, насколько я знаю, такого не произошло
Сборка мусора?
Исключения?
Автоматическое выполнение завершающих операций при выходе из контекста?
Наследование?
Полиморфизм?
Constraint-ы?
система категорий/типов?
модульность?
все это нужно для эффективной обработки деревьев или нет?
почему?
Исключения?
Автоматическое выполнение завершающих операций при выходе из контекста?
Наследование?
Полиморфизм?
Constraint-ы?
система категорий/типов?
модульность?
все это нужно для эффективной обработки деревьев или нет?
почему?
> Дело не в community, а в том, что это полновесный язык, удобный как раз для того же самого. Изобретая новый язык, можно было бы учесть опыт.
Я так понимаю, что на Lisp у большинства людей, принимающих решения, до сих аллергия.
Я так понимаю, что на Lisp у большинства людей, принимающих решения, до сих аллергия.
Что нужно по минимуму - я перечислил. Если считаешь, что есть что-то лишнее, попробуй убрать. Проблема в том, что в C-подобных языках этого нет (ну ладно, фиг с ним, с lexical scoping, и без макросов обойтись можно, если есть богатые встроенные шаблоны - но в С* их нет).
Перечисленные тобой рулезы реально могут быть полезны, но для обработки деревьев неспецифичны, а система типов сама по себе может и навредить (чтобы была польза, неплохо бы иметь импорт схем в систему типов языка, автоматическое выведение типа результата xpath-запроса из типа аргумента и наоборот; иначе придётся руками указывать приведения типов - нафиг не надо для обработки xml).
Но если нет декомпозиции деревьев, нет шаблонов - будет плохо, несмотря на всё остальное.
Перечисленные тобой рулезы реально могут быть полезны, но для обработки деревьев неспецифичны, а система типов сама по себе может и навредить (чтобы была польза, неплохо бы иметь импорт схем в систему типов языка, автоматическое выведение типа результата xpath-запроса из типа аргумента и наоборот; иначе придётся руками указывать приведения типов - нафиг не надо для обработки xml).
Но если нет декомпозиции деревьев, нет шаблонов - будет плохо, несмотря на всё остальное.
> Я так понимаю, что на Lisp у большинства людей, принимающих решения,
> до сих аллергия.
Хитрость в том, что не нужно сразу говорить, что это Лисп.
Просто в сторонке положить преобразователь из скобочек в теги и обратно, кому надо - найдут.
> до сих аллергия.
Хитрость в том, что не нужно сразу говорить, что это Лисп.
Просто в сторонке положить преобразователь из скобочек в теги и обратно, кому надо - найдут.
> но для обработки деревьев неспецифичны
почему? по каким критериям?
почему? по каким критериям?
Простые преобразования деревьев записываются просто и без этих наворотов. А вот без базовой поддержки деревьев на уровне языка - записываются сложнее, так как нужно руками писать сопряжения типов.
Simple things - easy.
Все дополнительные навороты могут помочь в выполнении второй части: hard things - possible. Тут надо ответить, что большая часть из перечисленного может быть реализована на чистом Лиспе. Модульность - единственное твёрдое исключение. Так как модульность добавляется в Лисп без нарушения его структуры, её нужно признать ортогональным свойством, желательным для сложных задач.
Свобода остаётся в том, какие преобразования называть простыми. Тут следует руководствоваться здравым смыслом, который может давать разные результаты. Поэтому, собственно, разные языки и появляются.
Simple things - easy.
Все дополнительные навороты могут помочь в выполнении второй части: hard things - possible. Тут надо ответить, что большая часть из перечисленного может быть реализована на чистом Лиспе. Модульность - единственное твёрдое исключение. Так как модульность добавляется в Лисп без нарушения его структуры, её нужно признать ортогональным свойством, желательным для сложных задач.
Свобода остаётся в том, какие преобразования называть простыми. Тут следует руководствоваться здравым смыслом, который может давать разные результаты. Поэтому, собственно, разные языки и появляются.
1. Получить данные из базы: SqlЯ начал использовать xslt просто ради интереса. Штука, конечно, мощная. Но убила такая вещь - как отлаживать сложные преобразования? Методомпристального вглядывания? Отладка просто убила наповал...
2. получить данные из внутренних источников: любимый язык программирования
3. Сформировать страницу: узкоспециализированный шаблонизатор
4. "Расскрасить" страницу на основе пожеланий пользователя: css
Затем возникла в общем-то очевидная мысль - бех xslt можно вообще-тообойтись, засунув преобразование в "любимый язык"(в моем случае С# который будет это делать не хуже.
Плюсы для себя я увидел такие:
- одной технологие меньше - меньше мороки в поддержке(в общем-то, ты об этом тоже писал, но в контексте xslt).
- работает быстрее
- можно реализовать все вкусности, которое присуще ООП+ простота последующего сопровождения и улучшения.
- отладчик (это очевидно, но это так так как как отлаживать слжный xslt я так и не понял.
Собственно такие мысли.
Комментарии?
> работает быстрее
Очень спорное утверждение. Есть какие-нибудь доводы?
> можно реализовать все вкусности, которое присуще ООП+ простота последующего сопровождения и улучшения.
Это ещё фиг знает, что проще: поддерживать и сопровождать код, написанный на довольно простом и очевидном XSLT, в котором гарантированно отсутствуют всякие побочные эффекты, или поддерживать код на полноценном языке программирования.
> отладчик (это очевидно, но это так так как как отлаживать сложный xslt я так и не понял.
Ты когда-нибудь программировал на Perl или Python? Я лет за 5 их использования ни разу не воспользовался интерактивным отладчиком.
Очень спорное утверждение. Есть какие-нибудь доводы?
> можно реализовать все вкусности, которое присуще ООП+ простота последующего сопровождения и улучшения.
Это ещё фиг знает, что проще: поддерживать и сопровождать код, написанный на довольно простом и очевидном XSLT, в котором гарантированно отсутствуют всякие побочные эффекты, или поддерживать код на полноценном языке программирования.
> отладчик (это очевидно, но это так так как как отлаживать сложный xslt я так и не понял.
Ты когда-нибудь программировал на Perl или Python? Я лет за 5 их использования ни разу не воспользовался интерактивным отладчиком.
ни на перлени на питоне программировать не доводилось. Да, я привык к отладчику. Он позволяет очень быстро разобраться в чужом коде, напомнить подзабытый собственный. Вообще-то не представляю как можно создавать более-менее сложные проекты безотладчика. Я б не смог.
Собственно своему коду доверяешь как-то больше,чемчерному ящику, даи гибкость налицо.
А простота (реализации и поддержки) в этом контесте практически синоним хорошего отладчика.
И о самочитаемости кода.
Хороший кодсамодокументируем. Публичная и приватная части, названия методов и параметров, грамотно расставленные ассерты - все это расскажет о программе получше докумментациии диаграмм uml.
xslt - там ничего этого нет. Это возвращение в каменный век
p.s. сорри, пробел заедает
вот такое имхо
Собственно своему коду доверяешь как-то больше,чемчерному ящику, даи гибкость налицо.
А простота (реализации и поддержки) в этом контесте практически синоним хорошего отладчика.
И о самочитаемости кода.
Хороший кодсамодокументируем. Публичная и приватная части, названия методов и параметров, грамотно расставленные ассерты - все это расскажет о программе получше докумментациии диаграмм uml.
xslt - там ничего этого нет. Это возвращение в каменный век
p.s. сорри, пробел заедает
вот такое имхо
Но убила такая вещь - как отлаживать сложные преобразования?Пользуйся VS 2005, там есть полноценный пошаговый отладчик.
Хороший код самодокументируем. Публичная и приватная части, названия методов и параметров, грамотно расставленные ассерты - все это расскажет о программе получше документациии диаграмм uml.На xslt-шках маленького размера проблема понимания не возникает. При большом размере xslt обычно можно (да и стоит) разделить на несколько более-менее независимых stylesheet-ов и сделать в главной stylesheet-ине import остальных. Читабельность повысится на порядок.
Также никто не отменял комментарии.
Вообще-то не представляю как можно создавать более-менее сложные проекты безотладчикаТы отладь под отладчиком хоть одну многотредовую программу (а других в "более-менее сложных проектах" как правило нет).
PS. Ничего самодокументирующегося в C# не вижу. Уметь надо программы хорошие писать = вводить адекватные понятия и операции над ними. А сделать (или не сделать) последнее можно на любом языке. А нет, на любом кроме brainfuck
Ты отладь под отладчиком хоть одну многотредовую программуа в чем проблема?
PS. Ничего самодокументирующегося в C# не вижу.При чем тут конкретный ЯП ?
Уметь надо программы хорошие писатьО том и речь, что в применении к xslt это умение реализовать очень сложно.
Пользуйся VS 2005, там есть полноценный пошаговый отладчик.не знал, поизучаю на досуге.
> а в чем проблема?
кстати, да, не вижу проблемы
кстати, да, не вижу проблемы
кстати, да, не вижу проблемыЧё тупим то?
Ошибка в многотредовой программе проявляется раз на 1000 запусков, и в тот день, когда ты усядешься отлаживать эту программу в отладчике уж тем более в пошаговом, будь уверен, все будет работать правильно.во-первых, не замечал, во-вторых, для таких случаев были придуманы бряки, в том числе, условные
найти, например, отсутствие блокировки или то, что потоки не в том порядке запускается - очень и очень тяжело с помощью отладчика.
хорошо, а с помощью чего просто? с помощью отладчика даже лики сложно искать, но альтернатива-то какая?
это так. Я пока вижу один выход - писать тщательнее тесты.
подумалось, а вот как tdd с шаблонизаторами применять?
подумалось, а вот как tdd с шаблонизаторами применять?
> хорошо, а с помощью чего просто? с помощью отладчика даже лики сложно искать, но альтернатива-то какая?
Самодиагностика, трассировка.
Самодиагностика, трассировка.
> подумалось, а вот как tdd с шаблонизаторами применять?
в чем проблема?
в чем проблема?
ну, трассировка - это понятно. Но ни за что не поверю, что трассировка без отладки удобнее отладки без трассировки
а самодиагностика - это что?
а самодиагностика - это что?
хотя да,нет проблем
подумалось о нативной среде, но можно и без нее обойтись
подумалось о нативной среде, но можно и без нее обойтись
> а самодиагностика - это что?
Грубо говоря - те же - assert-ы, но продвинутее.
Отслеживание корректности внутреннего состояния программы
Грубо говоря - те же - assert-ы, но продвинутее.
Отслеживание корректности внутреннего состояния программы
а самодиагностика - это что?я б ответил - assertions
> хорошо, а с помощью чего просто? с помощью отладчика даже лики сложно искать, но альтернатива-то какая?
Valgrind
Valgrind
Оставить комментарий
Werdna
Объясните мне, тупому, а нахуя технология XSLT? Я, конечно, с ней знаком крайне плохо, и только с точки зрения веба, не могу назвать ее полезной. Или я что-то не знаю?