Pull to refresh

Comments 3

Не сочтите за критику, но можно вопрос: А xlst преобразования в данном случае реально вам необходимы для задачи или просто для тренировки навыков и демонстрации xlst в статье? Просто я не заметил критичной причины, почему нельзя в данной задаче было сразу написать парсер в нужный формат xml, раз вы все равно уже парсер писали (и по сложности написания парсеры не сильно бы на мой взгляд отличались, но возможно я просто не увидел чего-то что нельзя сделать/или сложно сделать только с помощью парсера...). Но если вас интересовала именно тренировка работы с xlst, тогда вопрос снимается.
Да нет, вопрос на самом деле хороший. В идеале хочется видеть преобразование из ZRF и GDL. Это трудозатратно, но если возложить эту задачу на Java-код изменениями в парсере дело не ограничится (там логика сильно отличается и её трогать не хочется). Те преобразования которые уже есть, реализовать в парсере в общем то просто, но это без нужды усложнило бы его логику. Вообще мне нужен был XPath, а XSLT я рассматриваю как бонус, позволяющий решать задачи метапрограммирования. Не очень удобный, но «бесплатный». Проблема может возникнуть на мобильных платформах, поскольку Xalan весит не так уж мало. Там придется делать упрощенное внутреннее представление вместо DOM и отказаться от любых преобразований (в том числе от совместимости с ZRF и GDL). Это, в любом случае, задача не близкая.
Хочется верить, что XSLT станет несколько популярнее с появлением специального вычислительного облака под него. Там была бы поддержана лишь одна СУБД хранящая все данные в массиве xml-файлов, ну и язык поддерживался бы только один — XSLT. Язык хорош тем, что прост при всей мощности в реализации бизнес-логики, но его хочется обрамить более комфортной СУБД, ну и облачным удобством, что бы было как в Heroku или в нашем dokkur.com.
Стараюсь реализовать это в рамках проекта «формуляр» (https://github.com/m8data/formulyar).
Sign up to leave a comment.

Articles