XSLT – Собственная система сборки без конфигурации для Интернета ( github.com/pacocoursey )
Хорошо, это может быть маловероятно, но я бы сказал, что
1. в 1990-2000 годах браузеры были непоследовательны, поэтому мы начали использовать JS, чтобы заставить их вести себя одинаково
2. Между тем, единственное, что нам было нужно, — это хорошие стили CSS, которых еще не было, и согласованное поведение.
3. с годами браузеры стали вести себя одинаково (в основном потому, что Highlander рулит — может быть только один, но Firefox тоже неплохо справляется)
4. но мы уже привыкли к фреймворкам, которые делают страницы одинаковыми во всех браузерах. Также парадигма была переключена на рендеринг данных json
5. При нынешнем уровне технологий мы могли бы справиться со старыми веб-страницами, созданными на сервере, поскольку они занимают мало места, работают быстрее и требуют меньше памяти.
Почему я так говорю? Недавно мы начали работать над миграцией из устаревшей системы. Похоже на стандартную страницу 2000-х годов на HTTP-запрос. Каждое действие, например, добавить, удалить и т. д., требует http-обновления. Однако это работает гораздо быстрее, чем наша система React. Потому что:
1. В настоящее время интернет стал намного быстрее.
2. У телефонов много памяти, которая тратится впустую фреймворками js.
3. в бэкэнде все почти так же – CRUD CRUD и CRUD (+ пагинация, + транзакции)
Мне эта временная шкала не кажется правильной. JS редко использовался для стандартизации поведения — у нас было много обнаружения пользовательских агентов и опоры на упорядочивание причуд для принудительного выбора правильной компоновки. JS действительно был для интерактивности в начале — DHTML и позже AJAX. Я не думаю, что у него даже был легкий доступ к вещам, связанным с компоновкой? (Хотя я могу ошибаться) CSS тоже не сделал вещи более согласованными — как только он стал способен, он все еще был беспорядок. Конечно, CSS Garden был великолепен, и все были так впечатлены семантической разметкой, кодируя таблицы повсюду. Потребовались годы, чтобы что-то действительно прошло первые два ACID. Я не уверен, что фреймворки когда-либо действительно влияли на сторону «согласованного внешнего вида» — к тому времени, как мы выросли из jQuery, CSS был за внешний вид.
Но опять же, это было давно. Может, я неправильно помню.
При нынешнем уровне технологий мы могли бы справиться с веб-страницами старой школы, созданными на сервере, поскольку они занимают мало места, работают быстрее и требуют меньше памяти.
если у вас нет интернет-соединения с высокой задержкой: https://news.ycombinator.com/item?id=44326816
Однако, когда у вас соединение с высокой задержкой, веб-приложение с заполненным json “толстым клиентом” будет иметь свои преимущества только в том случае, если большая часть бизнес-логики происходит в браузере. То есть Google Docs – отлично и намного лучше, чем было в стиле дизайна 2000-х. Приложение, которое ищет квартиры для аренды? Я бы не сказал.
— редактировать —
Кстати, в 2005 году я программировал, используя очень забавный PHP-фреймворк PRADO, который отправлял все изменения в пользовательском интерфейсе на сервер. Боже, это было медленно и нагружало сервер. Это было направление, в котором мы никогда не должны были двигаться…
Одним из моих первых проектов в качестве профессионального инженера-программиста в зрелом возрасте 19 лет была настройка пары Google Search Appliances, которые купил мой работодатель. Они выложили сотни тысяч долларов за желтолицые серверы Dell, работающие под управлением CentOS с каким-то Google-y Python, потому что они думали, что возможность выполнять полнотекстовый поиск в огромных хранилищах документов CIFS упростит их процессы развития бизнеса. Около 2011 года XHTML был в моде, и modus operandi GSA заключался в преобразовании результатов поиска, выдаваемых из бэкэнда в XML, в XHTML через XSLT. Я взял стандартный шаблон и превратил его в нечестивое мерзость, которая служила чем-то, напоминающим остальную часть корпоративного интранет-портала, посредством активов и разметки, украденных из визуализированных страниц приложений Coldfusion, StackOverflow и учебных пособий W3Schools.
Я быстро понял, что не стоит включать этот конкретный опыт в свое резюме, поскольку различные подрядчики Министерства обороны связывались со мной на LinkedIn, предлагая свои «знания в области XML» для участия в различных проектах по модернизации документации.
В следующий раз, когда вы будете вздыхать, используя JSX для итерации по массиву интерфейсов Typescript, десериализованных из ответа JSON, вспомните этот пост — вы могли бы оказаться мной, делающим то же самое в XSLT :-).
Печально, что раздутость корпоративного XML нулевых сделала эту технологию устаревшей и заставила всех перейти на «более чистый» JSON, поскольку такие вещи, как XSLT и XPath, были очень зрелыми и решали множество проблем, с которыми мы до сих пор сталкиваемся в других форматах.
Я, вероятно, виновен в некоторых плохих практиках: у меня остались приятные воспоминания о том, как в свое время я (аб)использовал XSLT-включения с PHP-обёртками потоков, чтобы иметь что-то вроде `
Это может быть устаревшим предубеждением, но мне все еще немного не по себе позволять браузеру делать это локально, просто потому что раньше это было минным полем несовместимости.
Xpath был бы хорош, если бы вам не приходилось педантично создавать пространство имен для каждого бита каждого запроса
Мне нравится XSLT, именно на него я перевел свой сайт после этапа CGI.
К сожалению, это мнение разделяют не многие, и у многих разработчиков всегда возникали проблемы с пониманием подхода функционального проектирования, выходящего за рамки XML.
25 лет спустя форматы JSON и YAML изобретают велосипед, причем в основном неудачно, поскольку все это уже было доступно в экосистеме XML.
Схемы, проверка, графические инструменты преобразования, структурированные редакторы, комментарии, плагины, пространства имен,…
В настоящее время я использую XSLT для стилизации своих каналов. Например:
XSLT — это круто, и он был для меня весьма расширяющим кругозор, когда он появился — я бы не сказал, что это технология уровня «grug brain» вообще. XML-язык для манипулирования XML — может быть довольно запутанным и «мета». Я бы не выбрал его в качестве инструмента в наши дни.
Я работал с XSLT почти с самого начала своей карьеры, и это было благословение. Респект Майклу Кею.
Моя первая стажировка была в Intel на процессоре XSLT 2.0. Майкл Кей действительно легенда. IIRC, Saxon был его единоличным творением. Безумие!
Что это за “XSLT работает изначально в браузере”? Последний раз я использовал XSLT лет 20 назад, но я использовал его МНОГО, В ТЕЧЕНИЕ ЛЕТ. В те дни для его работы требовалась огромная шаткая башня корпоративного Java, что несколько умаляло элегантность самого XSLT. Но если XSLT действительно работает в браузере, неужели Святой Грааль статического шаблона host-anywhere все это время находился у нас под носом?
В 2008 году я работал с сайтом, использующим XSLT в браузере, но, по-моему, его поддержка появилась еще в начале 2000-х.
Я был _действительно_ глубоко погружен в XSLT – я даже написал парсер XSLT 2 для Википедии где-то в 2009 году, так что я не уверен, почему я не знал о встроенной поддержке браузеров для преобразований до сих пор. Или, может быть, я знал, но просто забыл.
> как мне его запустить? открыть XML-файл > открыть blog.xml -a Safari
Это не сработало у меня в браузерах (FF/Chrome/Safari) на Mac, судя по всему, XSLT там работает только при доступе через HTTP:
$ python3 -m http.server –directory . $ open http://localhost:8000/blog.xml Я помню долгие часы использования XSLT для преобразования пользовательских форматов XML в какое-то другое представление, которое использовалось WXWindows в 2000-х годах. Может быть, мне стоит снова попробовать это для Web 🙂
https://packages.grpc.io — это XML-страница, стилизованная с помощью XSLT, обновляемая скриптом bash в CI
Я простой человек. Я вижу readme пещерного человека, мне нравится. Иногда я чувствую себя пещерным человеком, который стучит по клавиатуре, чтобы заставить машину делать нехорошие вещи. Но иногда, вещи хорошие. Я не делаю веб-сайты или веб-вещи, но я не знаю о XSLT. Я иногда взламываю XML. Я иногда хочу показать пользователю вещи. Много-много разных форматов файлов заставляют голову болеть. Мне нравятся красивые вещи. Мне может пригодиться это.
Спасибо, что прочитали спецификации.
Спасибо за создание инструмента.
Я некоторое время назад изучал это и пришел к выводу, что это работает нормально, но браузеры бурно кричат о том, что его следует отменить, поэтому в итоге пришлось запустить преобразование локально, чтобы получить html5. Разочарование.
На моей первой работе, когда .net еще не существовало, xml + xslt был шаблонизатором, который мы использовали для html и (html) электронной почты, а иногда и csv. Я писал запросы на сервере sql с использованием “for xml”, и он выводил все данные, необходимые для страницы, и передавал их в шаблон xsl (все на стороне сервера), который выводил html. У Microsoft был кеширующий парсер xsl, который мог бы загрузить такую страницу менее чем за 10 мс. До тех пор, пока мы не подумали “эй, давайте начнем использовать пространства имен xml, это звучит как хорошая идея!”. После этого было немного менее весело! Оглядываясь назад, это был довольно хороший стек, и он все еще отлично работает сегодня, имхо. Он никогда не начинал мне не нравиться, но после того, как я ушел с этой работы, я больше никогда не писал таблиц стилей.
Я помню, что я делал то же самое в 2005-2006 годах, просто объединял XML с XSL(T), чтобы браузер мог преобразовать XML в HTML. После этого также объединял XML с XSL(T) с PHP. В то время современный способ работы, разделение проблем во фронтенде. Около 2008-2009 годов я прекратил использовать этот метод и начал использовать, например, smarty. Мне все еще нравится идея использования всех собственных методов браузеров, которые описаны в W3c. Не нужны фреймворки или библиотеки, сохраняйте простоту и надежность.
Думаю, сейчас мало кто знает XSL(T) или нуждается в обновлении знаний (как я).
Иногда мне хотелось бы, чтобы мы могли сохранить XML живым наряду с JSON.. Мне не хватает комментариев, CDATA и т. д., особенно когда вам нужно сериализовать сложное состояние. Я знаю, что есть альтернативы JSON, такие как YAML, но я чувствовал, что XML лучше, чем YAML. Мы приняли JSON из-за его простоты, но попытались модернизировать схему и другие вещи, которые сделали XML сложным. Как будто мы как бы заново изобрели схему JSON, и в итоге получилось то, что XSD сделал десятилетия назад, и до сих пор не нашли хорошей альтернативы XSLT..
Эквивалентом XSL:T для JSON является React.
Давайте не будем романтизировать XML. Я написал целое приложение, которое использовало XSL:T около 25 лет назад (это был военный контракт, и по какой-то причине требовалось использование базы данных XML, не спрашивайте меня). Да, у него были некоторые преимущества перед JSON, но XSL:T было полной болью для работы в масштабе. Это функциональный язык, поэтому вам сначала нужно войти в этот образ мышления. Затем, на самом деле, это несколько функциональных языков, составленных вместе, поэтому вам также нужно изучить XPath, который лишь немного более дружелюбен, чем регулярные выражения. В языке доминируют хаки, работающие над тем фактом, что он использует XML в качестве своего синтаксиса. И нет (не было?) полезных отладчиков или других инструментов. Я не знаю, у вас даже не было эквивалента отладки printf. Если вы где-то облажались, вы просто получали неправильный вывод.
По сравнению с этим React намного лучше. Синтаксис намного чище и более уместен, вы можете смешивать императив и ФП, у вас есть надлежащие инструменты отладки и профилирования, и он поддерживает инкрементальное повторное преобразование, так что он действительно полезен для интерактивного пользовательского интерфейса, тогда как XSL:T никогда не был таким, так что вам в любом случае нужен был JS.
Мне просто пришлось объяснить некоторым новичкам, что SOAP — это протокол с жесткими правилами; REST — это архитектурный стиль с гибкостью. Последнее означает, что вам придется очень хорошо работать и документировать, а потребителям API нужны инструменты вроде Postman и т. д., чтобы вообще иметь возможность использовать API. С SOAP вы получаете большую часть этого бесплатно.
Я полностью согласен, но библиотека XML в их экосистеме JS — дерьмо.
Ого, я только что понял, насколько шаблоны страниц Zope по сути являются XSLT, которые выглядят немного иначе.
Это дает мне новое понимание того, насколько мощным является XSLT, и как я рад, что могу использовать почти все остальное, чтобы получить те же самые конечные результаты. Дайте мне Jinja или Mustache в любой день. Просто старые добрые s-exprs, если на то пошло. Только, пожалуйста, никогда больше не заставляйте меня писать XML с XML.
У меня есть статический сайт с меню. Синхронизация меню на полудюжине страниц — это проблема.
Единственным вариантом исправить это являются JavaScript, XSLT или серверный генератор HTML. (И прежде чем вы спросите, статические генераторы сайтов ничем не лучше, они просто делают генерацию вручную, а не автоматически.)
На самом деле мне все равно, статичен ли сайт. Мне важно только, чтобы его было просто поддерживать.
Инструменты сборки не просты. Они, как правило, страдают от битрота, поскольку не связаны с хостингом сайта или его содержимым.
Генераторы HTML на стороне сервера (они же системы управления контентом и т. д.) имеют большой размер и привязывают меня к определенной платформе.
Фреймворки фронтенда по умолчанию требуют шага сборки и, конечно, требуют JavaScript в браузере. Некоторые фреймворки можно включить без инструментов сборки, и это лучше, но также излишне для больших сайтов. И, конечно, тогда вы привязаны к фреймворку.
Другой вариант — написать собственный код JavaScript для включения фрагмента HTML из другого файла.
или, может быть, я могу попробовать включить include с помощью xslt. Заткнет ли это рот тем, кто хочет просматривать мой сайт без JavaScript?
в какой-то момент обсуждалось включение HTML, но оно было прекращено. почему?
Кто-нибудь помнит Cocoon? Это был XSLT Web Framework, построенный на Spring. Он был довольно аккуратным, можно было делать то, в чем XSLT был хорош, с таблицами стилей, которые были сопоставлены с маршрутами HTTP, и его было очень легко расширить с помощью пользовательских функций и поддержки кода Java, чтобы делать то, в чем он был не очень хорош. Хотя должен сказать, что по мере того, как таблицы стилей XSLT становились все сложнее, их становилось *действительно* трудно понять, особенно по сравнению с чем-то вроде шаблона Jinja.
Я сделал веб-сайт на основе XML-документов и преобразований XSLT около 20 лет назад. Мне очень понравилась эта концепция. Инфраструктуру можно было бы сделать намного проще, но, думаю, мне хотелось иметь повод поиграть с этими технологиями.
Проведя месяцы за работой на своей машине для разработки, я развернул сайт на своем VPS и с ужасом обнаружил, что модуль XSLT не активирован в конфигурации PHP. Мне пришлось попросить (небольшую) компанию обновить их установку PHP специально для меня, что они быстро и сделали.
В начале своей карьеры я работал над мобильным интернет-порталом оператора в дни до смартфонов. Это был XSLT от начала до конца, включая отдельные преобразования XSLT для каждого компонента CMS для каждого поддерживаемого нами телефона (сотни), поскольку у всех были разные возможности и ошибки браузера. Было не так уж весело писать сложную логику на haha, но это было довольно интересным занятием, пока не появились iPhone и т. д., и все не могли просто отображать обычные веб-сайты.
То же самое. Я был частью развертывания мобильных медиа-сообщений (WAP) в Vodafone. О, черт, XSLT был одним из тех “теоретических” языков W3C, которые (справедливо) стареют как молоко. Никогда больше.
Ха! Я был в Orange. Подозреваю, что у всех операторов были похожие настройки. Да, я не скучаю по работе с этим, лол
В тот же период я работал в финском стартапе (iobox.fi), который в итоге был приобретен Telefonica.
Наш мобильный и веб-портал был создан на основе служб j2ee, создающих XML, которые затем были преобразованы с помощью XSLT в HTML или WAP.
В то время меня поразило, что они ожидали, что веб-дизайнеры будут работать на таком эзотерическом языке.
Но он также был хорошо разделен
В то время я сделал несколько нетривиальных проектов с XSLT, и проблема с ним заключается в отсутствии хорошей мнемоники, возможности обнаружения из исходного кода и других эргономических характеристик в сочетании с тем фактом, что он используется редко, поэтому вы обнаруживаете себя фактически переучивающимся, если не использовали его в течение пары недель. Соответствие специфичности шаблона — особенно плохая идея в таких обстоятельствах.
XSLT технически будет иметь смысл, чем больше вы используете большое количество шаблонных XML-литералов в своем шаблоне, потому что он использует сам XML как синтаксис языка. Но даже при использовании XML как метасинтаксиса языка, он имеет много микросинтаксиса, т. е. XPath, переменных, параметров, которые вам нужно втиснуть в атрибуты XML с обычными ограничениями кавычек и отсутствием подсветки синтаксиса. На самом деле в XSLT нет ничего, что нельзя было бы реализовать лучше с помощью языка общего назначения с надлежащим тестированием и библиотечной инфраструктурой, такой как Prolog/Datalog (на самом деле, DSSSL, близкий предшественник XSLT для шаблонизации полного SGML/HTML, а не только подмножества XML, был основан на Scheme) или просто, вы знаете, ванильный JavaScript, который был введен для манипуляции DOM.
Обратите внимание, что поддержка libxml2/libxslt в настоящее время недостаточна [1], и для меня чудо, что XSLT (версия v1.0 от 1999 года) поставляется как нативная реализация в браузерах, в отличие, например, от PDF.js.
[1]: https://gitlab.gnome.org/GNOME/libxml2/-/issues/913
Я использую XSLT для генерации README-файла markdown из XML-файла экспорта Zotero. Он работает хорошо, но некоторые простые вещи становятся намного сложнее — сортировка, подсчет, уникальность.
https://github.com/captn3m0/boardgame-research
К тому же он кажется очень загадочным — к сожалению, его трудно отладить и понять.
Я разочарован, что это использует пользовательский формат XML, а не RSS (терпимо) или Atom (лучше). Тогда вы могли бы просто закинуть его в читалку фидов.
Несколько лет назад я решил оформить свои собственные ленты и в итоге получил вот это: https://chrismorgan.info/blog/tags/fun/feed.xml . https://chrismorgan.info/atom.xsl довольно подробный, не думаю, что вы найдете такой с более полной поддержкой функций. (Я написал его вариант и для RSS, так как в то время думал о подкастах, а почти все программное обеспечение для подкастов глупое и не поддерживает Atom, и это все вина Apple : https://temp.chrismorgan.info/2022-05-10-rss.xsl .)
В то время я серьезно задумался о том, чтобы сделать следующую итерацию моего сайта обслуживающей все материалы блога как документы Atom — списки постов как ленты, а отдельные страницы как записи. В конце концов, я решил пойти в совершенно другом направлении (включив много рукописного текста!), но я не думаю, что эта идея плоха.
Привет из прошлого. Я на самом деле довольно много использовал XSLT в начале нулевых. В конце концов, я думаю, все поняли, что XML — это уродливый способ писать S-выражения.
Много-много лет назад я использовал Symphony21[0] для сайта мероприятий. Вся его предпосылка заключалась в построении XML-структуры через чертежи, а затем ваша тема — это просто XSLT-шаблоны для страниц.
Бросил, потому что оказалось, что мелочи — это просто головная боль. Форматирование дат, отображение номеров статей и их количества и т. д.
[0] https://www.getsymphony.com/
Ого, привет из прошлого.
Вся эта суета только ради того, чтобы развернуть статический веб-сайт на Vercel? :p
Мы снова прошли полный круг. Да, это прекрасно работает уже много лет, XML — это просто беспорядок.
Старый добрый xslt. Был в центре внимания, когда строгий xml все еще был следующим кандидатом на стандарт. Победил html5.
xslt делает одну вещь: просматривает деревья на входных данных дерева. И данные, и макет остаются в структурированной памяти. Никаких случайных переходов. Собственный браузерный eval xslt может достигать точек производительности, которые могут пропустить большинство библиотек json-to-dom. Размещение памяти было выровнено по замыслу. Мы отказались от него слишком рано, просто потому, что xml стал непопулярным
XSLT — это очень весело как общий функциональный язык программирования! Вы можете создавать собственные функциональные структуры данных[1], реализовывать алгоритмы обхода графов[2] и даже писать тестовые утверждения[3]!
1: https://github.com/pjlsergeant/xslt-fever-dream/blob/main/ma…
2: https://github.com/pjlsergeant/xslt-fever-dream/blob/main/gr…
3: https://github.com/pjlsergeant/xslt-fever-dream/blob/main/ta…
Blizzard использует/использовала XSLT для WoW.
Это было до/после принятия LUA?
До. И после.
XSLT управляет стилем, Lua — запущенными функциями. Когда Lua корректирует видимую вещь, он генерирует XSLT.
«FrameXML» — это тонкая оболочка Lua вокруг базового XSLT.
Ненавижу этот стиль письма grug brain. Звучит отвратительно и его трудно читать. Пожалуйста, просто пишите нормальные, полные предложения.
Да, я не понимаю. Мне пришлось прекратить читать после пары предложений, я просто не могу с этим справиться.
Вероятно, часть цели — неявно заявить, что описываемое настолько просто, что даже пещерный человек мог бы это понять. Но писать такой пост о XSLT — это как сатира. Дальше — статья grug brain о помощнике доказательства Coq?
Может быть, это просто манера письма автора?
Не могу воспринимать это всерьез, когда говоришь таким языком, извините.
я занят починкой асан, «незаконное указание», бла-бла-бла, я печален и расстроен, очень хмурый.
Я пришел в hn, увидел систему сборки XML, я счастлив, очень улыбаюсь, я нажал стрелку вверх, я поблагодарил доброго незнакомца.
Боже мой, какой стиль написания в этой статье!
Source: news.ycombinator.com