Действительно ли XSLT стоит того? [закрытый]

XSLT не является концом - все самое важное xml преобразования. Однако очень трудно судить на основе информации, данной, если это было бы лучшее решение Вашей проблемы или если существуют другие более эффективные и удобные в сопровождении подходы. Вы говорите, что авторы могли ввести свое содержание в упрощенный формат - что формат? Текстовые поля? В какой HTML Вы преобразовывали его? Чтобы судить, является ли XSLT правильным инструментом для задания, это помогло бы знать функции этого преобразования более подробно.

Я люблю использовать XSLT только для изменения древовидной структуры XML-документов. Я нахожу его громоздким, чтобы сделать что-либо связанное с обработкой текста и понизить это к пользовательскому сценарию, который я могу выполнить прежде или после применения XSLT к XML-документу.

XSLT 2.0 включал намного больше строковых функций, но я думаю, что это не подходящий вариант для языка, и нет многих реализаций XSLT 2.0.

Для меня в настоящее время определяют задачу с очисткой данных из общедоступного сайта (да, я знаю). К счастью это соответствует xhtml, таким образом, я в состоянии использовать xslt для сбора данных, в которых я нуждаюсь. Получающееся решение является читаемым, чистым и легким измениться, если потребность происходит. Прекрасный!

Я провел много времени в XSLT и нашел, что, в то время как это - полезный инструмент в некоторых ситуациях, это - определенно не фиксация все. Это работает очень хорошо на цели B2B, когда это используется для преобразования данных для машиночитаемого ввода/вывода XML. Я не думаю, что Вы находитесь на ложном пути в Вашем операторе его ограничений. Одной из вещей, которые расстроили меня большинство, были нюансы в реализациях XSLT.

, Возможно, необходимо посмотреть на некоторые из других доступных языков разметки. Я полагаю, что Jeff сделал статью об этой самой теме относительно Переполнения стека.

действительно ли HTML является Гуманным Языком разметки?

я смотрел бы на то, что он записал. Можно, вероятно, найти пакет программного обеспечения, который делает то, что Вы хотите "из поля", или по крайней мере очень близко вместо того, чтобы писать Ваш собственный материал с нуля.

Я был бы определенно reccomend для высовывания его. Особенно, если Вы используете Visual Studio, которая создала в редактировании, просмотре и средствах отладки для XSLT.

Да, это - боль, в то время как Вы учитесь, но большая часть боли относится к знакомству. Боль действительно уменьшается, поскольку Вы учите язык.

W3schools имеет две статьи, которые имеют конкретную ценность: http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

Я помню всю шумиху вокруг XSLT, когда стандарт был недавно выпущен. Все волнение вокруг способности создало весь HTML UI с 'простым' преобразованием.

Let’s стоят перед ним, трудно использовать, почти невозможный отладить, часто невыносимо замедлиться. Конечный результат является почти всегда изворотливым и меньше, чем идеал.

я буду раньше грызть от своего собственного участка, чем использование XSLT, в то время как существуют лучшие способы сделать вещи. Тем не менее это имеет свои места, свою пользу для простых задач преобразования.

Лично я использовал XSLT в полностью различном контексте. Компьютерная игра, что я продолжал работать в то время используемые тонны страниц UI, определенных с помощью XML. Во время майора осуществляют рефакторинг вскоре после выпуска мы хотели изменить структуру этих XML-документов. Мы заставили формат ввода игры следовать за намного лучшим и схемой осведомленная структура.

XSLT казался отличным выбором для этого перевода из старого формата-> Новый формат. В течение двух недель у меня было рабочее преобразование от старого до нового для наших сотен страниц. Я также смог использовать его для извлечения большой информации о расположении наших страниц UI. Я создал списки, из которых были встроены компоненты, в котором, относительно легко который я тогда использовал XSLT для записи в наши определения схемы.

кроме того, происходя из среды C++, это был очень забавный и интересный язык ведущему устройству.

я думаю, что как инструмент для перевода XML от одного формата до другого это фантастически. Однако это не единственный способ определить алгоритм, который берет XML в качестве входа и выводов Что-то . Если Ваш алгоритм достаточно сложен, то, что вход является XML, становится не важным Вашему выбору инструмента - т.е. самокрутка в C++ / Python / безотносительно.

Характерный для Вашего примера, я предположил бы, что лучшая идея будет состоять в том, чтобы создать Ваш собственный XML->, XML преобразовывают, который следует за Вашей бизнес-логикой. Затем, запишите переводчика XSLT, который просто знает о форматировании и не делает ничего умного. Это могло бы быть хорошим вторым планом, но он полностью зависит, что Вы делаете. Наличие переводчика XSLT на выводе облегчает создавать альтернативные выходные форматы - печатаемый, для мобильных телефонов, и т.д.

Я нашел, что XSLT является довольно трудным работать с.

у меня был опыт при работе над системой, несколько подобной той, которую Вы описываете. Моя компания отметила, что данные, которые мы возвращали из "среднего уровня", были в XML, и что страницы должны были быть представлены в HTML, который мог бы также быть XHTML, плюс они услышали, что XSL был стандартом для преобразования между форматами XML. Так "архитекторы" (которым я имею в виду людей, которые думают глубокие мысли дизайна, но по-видимому никогда не кодируют), решил, что наш передний уровень будет реализован путем записи сценариев XSLT, которые преобразовали данные в XHTML для дисплея.

выбор оказался имеющим катастрофические последствия. XSLT, это складывается, является болью для записи. И таким образом, все наши страницы было трудно записать и поддержать. Мы сделали бы намного лучше для использования JSP (это было в Java), или некоторый аналогичный подход, который использовал один вид разметки (угловые скобки) для выходного формата (HTML) и другой вид разметки (как < %... %>) для метаданных. Самая запутывающая вещь о XSLT состоит в том, что он записан в XML, и он переводит от XML до XML..., довольно трудно сохранить все 3 различных XML-документа прямо в уме.

Ваша ситуация немного отличается: вместо того, чтобы создать каждую страницу в XSLT, как я сделал, только необходимо записать один бит кода в XSLT (код для преобразования из шаблонов для отображения). Но это кажется, что Вы, возможно, столкнулись с тем же видом трудности, которую я сделал. Я сказал бы, что попытка интерпретировать простой основанный на XML DSL (предметно-ориентированный язык) как Вы делает, не одна из сильных сторон XSLT. (Хотя это, CAN делает задание..., в конце концов, это полно по Тьюрингу!)

Однако, если то, что Вы имели, было более простым: у Вас есть данные в одном формате XML и требуемый для создания простых изменений к нему - не полностраничное описание DSL, но некоторые простые простые модификации, тогда XSLT является превосходным инструментом с этой целью. Это декларативно (не процедурный), природа является на самом деле преимуществом с этой целью.

- Michael Chermside

XSLT является трудным работать с, но как только Вы завоевываете его, у Вас будет очень полное понимание DOM и схемы. Если Вы также XPath, то Вы на Вашем пути к изучению функционального программирования и это подвергнет новым методам и путям о решении проблем. В некоторых случаях последовательное преобразование более мощно, чем процедурные решения.

спецификация XSLT определяет XSLT как "язык для преобразования XML-документов в другие XML-документы". При попытке сделать какую-либо вещь, но обработку наиболее основных данных в XSLT существуют, вероятно, лучшие решения.

Также стоящий замечания, что возможности обработки данных XSLT могут быть расширены в.NET с помощью пользовательских дополнительных функций:

• Документация MSDN
• CSharpFriends: Учебное руководство

Я поддерживаю систему интерактивной документации для своей компании. Писатели создают документацию в SGML (xml как язык). SGML тогда объединен с XSLT и преобразован в HTML.

Это позволяет нам легко вносить изменения в расположение документации, не делая никакого кодирования. Его просто вопрос изменения XSLT.

Это работает хорошо на нас. В нашем случае это - документ только для чтения. Пользователь не взаимодействует с документацией.

кроме того, при помощи XSLT, Вы работаете ближе к Вашей проблемной области (HTML). Я всегда полагаю что быть хорошей идеей.

Наконец, если Ваша существующая система РАБОТЫ, оставьте его в покое. Я никогда не предлагал бы повредить Ваш существующий код. Если бы я запускал с нуля, я использовал бы XSLT, но в Вашем случае, я использовал бы то, что Вы имеете.

Это сводится к тому, для чего Вы нуждаетесь в нем. Ее основная сила является легкой пригодностью для обслуживания преобразования и записью, что Ваш собственный синтаксический анализатор обычно стирает это. После этих слов иногда система является маленькой и простой и действительно не нуждается в "необычном" решении. Пока Ваш основанный на коде разработчик заменим, не имея необходимость изменять другой код, никакое грандиозное предприятие.

Что касается уродства XSL, да это ужасно. Да, требуются некоторые привыкающие к. Но как только Вы приобретаете навык его (не должен занимать много времени IMO), это - на самом деле гладкий парусный спорт. Скомпилированный преобразовывает выполненный вполне быстро, по моему опыту, и можно, конечно, отладить в них.

Я все еще полагаю, что XSLT может быть полезным, но это - ужасный язык и может привести к ужасной нечитабельной, неудобной в сопровождении путанице. Частично, потому что XML не достаточно человекочитаем для составления "языка" и частично потому что XSLT застревает где-нибудь между тем, чтобы быть декларативным и процедурным. Однако и я думаю, что сравнение может проводиться с регулярными выражениями, оно имеет, это - использование когда дело доходит до простых четко определенных проблем.

Используя альтернативный подход и анализирующий XML в коде может быть одинаково противным, и Вы действительно хотите использовать некоторый XML маршалинг/привязка технологии (такой как JiBX в Java), который преобразует Ваш XML прямо в объект.

Так много отрицательности!

я использовал XSLT в течение многих лет теперь, и действительно люблю его. Ключевая вещь, которую необходимо понять, состоит в том, что это не язык программирования, это - язык шаблонной обработки (и в этом отношении я нахожу его неопределенно выше asp.net / слюна).

XML является фактическим форматом данных веб-разработки сегодня, быть им файлы конфигурации, необработанные данные или в памяти reprsentation. XSLT и XPath дают Вам чрезвычайно мощный и очень эффективный способ преобразовать те данные в любой выходной формат, который Вы могли бы любить, немедленно давая Вам что аспект MVC разделения представления от данных.

Тогда существуют служебные способности: размытие пространств имен, распознавая разрозненные определения схемы, объединяя документы.

Это должно быть лучше иметь дело с XSLT, чем разработка Ваших собственных внутренних методов. По крайней мере, XSLT является стандартом и чем-то, что Вы могли нанять для, и если бы это - когда-нибудь действительно проблема для Вашей команды, это - очень природа, позволил бы Вам сохранить большую часть своей работы в команде только с XML.

вариант использования реального мира А: Я просто записал приложение, которое обрабатывает документы XML в оперативной памяти по всей системе и преобразовывает к JSON, HTML или XML согласно просьбе конечным пользователем. У меня был довольно случайный запрос для обеспечения как данные Excel. Бывший коллега сделал что-то подобное программно, но оно потребовало модуля нескольких файлов класса и что серверу установили MS Office! Оказывается, что Excel имеет XSD: новая функциональность с минимумом basecode влияет за 3 часа.

Лично я думаю, что это - одна из самых чистых вещей, с которыми я встретился в своей карьере, и я верю всему, ему - очевидные проблемы (отладка, обработка строк, программируя структуры) до дефектного понимания инструмента.

, Очевидно, я сильно полагаю, что это "стоит того".

Чтобы ответить на три ваших вопроса:

1. Я использовал XSLT несколько лет назад.
2. Я действительно считаю, что XSLT может быть правильным решением в определенных обстоятельствах. (Никогда не говори никогда)
3. Я склонен согласиться с вашей оценкой, что это в основном полезно для «простых» преобразований. Но я думаю, что до тех пор, пока вы хорошо понимаете XSLT, есть основания использовать его для более серьезных задач, таких как публикация веб-сайта в виде XML, преобразованного в HTML.

Я считаю, что причина, по которой многие разработчики не любят XSLT, заключается в том, что они не понять принципиально иную парадигму, на которой она основана. Но с недавним интересом к функциональному программированию мы можем увидеть возвращение XSLT ...

Одно из преимуществ xslt - создание отчетов. Я обнаружил, что это двухэтапный процесс: первый шаг - экспорт данных отчета в виде файла xml, а второй шаг - создание визуального отчета из xml с использованием xslt. Это позволяет создавать красивые визуальные отчеты, сохраняя при этом необработанные данные в качестве механизма проверки, если это необходимо.

В предыдущей компании мы много работали с XML и XSLT. И XML, и XSLT большие.

Да, есть кривая обучения, но тогда у вас есть мощный инструмент для работы с XML. И вы даже можете использовать XSLT в XSLT (что иногда может быть полезно).

Производительность также является проблемой (с очень большим XML), но вы можете решить эту проблему, используя умный XSLT и сделав некоторую предварительную обработку с (сгенерированным) XML.

Любой, кто знаком с XSLT, может изменить внешний вид готового продукта, поскольку он не компилируется.

Я использовал XSLT раньше. Группа из 6 файлов .xslt (преобразованных из одного большого) занимала около 2750 строк задолго до того, как я переписал ее на C #. Код C # в настоящее время состоит из 4000 строк, содержащих много логики; Я даже не хочу думать о том, что потребовалось бы для написания в XSLT.

Я сдался, когда понял, что отсутствие XPATH 2.0 значительно мешает моему прогрессу.

We use XSLT extensively for things like documentation, and making some complex configuration settings user-serviceable.

For documentation, we use a lot of DocBook, which is an XML-based format. This lets us store and manage our documentation with all of our source code, since the files are plain text. With XSLT, we can easily build our own documentation formats, allowing us to both autogenerate the content in a generic way, and make the content more readable. For example, when we publish release notes, we can create XML that looks something like:

<ReleaseNotes>
    <FixedBugs>
        <Bug id="123" component="Admin">Error when clicking the Foo button</Bug>
        <Bug id="125" component="Core">Crash at startup when configuration is missing</Bug>
        <Bug id="127" component="Admin">Error when clicking the Bar button</Bug>
    </FixedBugs>
</ReleaseNotes>

And then using XSLT (which transforms the above to DocBook) we end up with nice release notes (PDF or HTML usually) where bug IDs are automatically linked to our bug tracker, bugs are grouped by component, and the format of everything is perfectly consistent. And the above XML can be generated automatically by querying our bug tracker for what has changed between versions.

The other place where we have found XSLT to be useful is actually in our core product. Sometimes when interfacing with third-party systems we need to somehow process data in a complex HTML page. Parsing HTML is ugly, so we feed the data through something like TagSoup (which generates proper SAX XML events, essentially letting us deal with the HTML as if it were properly written XML) and then we can run some XSLT against it, to turn the data into a "known stable" format that we can actually work with. By separating out that transformation into an XSLT file, that means that if and when the HTML format changes, the application itself does not need to be upgraded, instead the end-user can just edit the XSLT file themselves, or we can e-mail them an updated XSLT file without the entire system needing to be upgraded.

I would say that for web projects, there are better ways to handle the view side than XSLT today, but as a technology there are definitely uses for XSLT. It's not the easiest language in the world to use, but it is definitely not dead, and from my perspective still has lots of good uses.

XSLT - это пример декларативного языка программирования .

Другие примеры декларативных языков программирования включают регулярные выражения, Пролог и SQL. Все они очень выразительны и компактны, и обычно очень хорошо разработаны и мощны для той задачи, для которой они созданы.

Однако разработчики программного обеспечения обычно ненавидят такие языки, потому что они настолько отличаются от более распространенных объектно-ориентированных или процедурных языков, которые их сложно изучить и отладить. Их компактная природа обычно позволяет легко нанести большой ущерб непреднамеренно.

Таким образом, хотя XSLT является эффективным механизмом для объединения данных в представление, он не работает с точки зрения простоты использования. Я считаю, что именно поэтому он не прижился.

I've used XSLT (and also XQuery) extensively for various things - to generate C++ code as part of build process, to produce documentation from doc comments, and within an application that had to work with XML in general and XHTML in particular a lot. The code generator in particular was in excess of 10,000 lines of XSLT 2.0 code spread around about a dozen separate files (it did a lot of things - headers for clients, remoting proxies/stubs, COM wrappers, .NET wrappers, ORM - to name a few). I inherited it over another guy who didn't really understand the language well, and the older bits were consequently quite a mess. Newer stuff that we wrote was mostly kept sane and readable, however, and I do not recall any particular problems with achieving that. It was certainly not any harder than doing it for C++.

Speaking of versions, dealing with XSLT 2.0 definitely helps keep you sane, but 1.0 is still alright for simpler transforms. In its niche, it is an extremely handy tool, and the productivity you get from certain domain-specific features (most importantly, dynamic dispatch via template matching) is hard to match. Despite the perceived wordiness of XSLT's XML-based syntax, the same thing in LINQ to XML (even in VB with XML literals) was usually several times longer. Quite often, however, it gets undeserved flack because of unnecessary use of XML in some case in the first place.

To sum it up: it is an incredibly useful tool to have in one's toolbox, but it is a very specialized one, so it is good so long as you use it properly and for its intended purpose. I really wish there was a proper, native .NET implementation of XSLT 2.0.

I use XSLT (for lack of better alternative), but not for presentation, just for transformation:

1. I write short XSLT transformations to do mass edits on our maven pom.xml files.

2. I've written a pipeline of transformations to generate XML Schemas from XMI (UML Diagram). It worked for a while, but it finally got too complex and we had to take it out behind the barn.

3. I've used transformations to refactor XML Schemas.

4. I've worked around some limitations in XSLT by using it to generate an XSLT to do the real work. (Ever tried to write an XSLT that produces an output using namespaces that aren't known until runtime?)

I keep coming back to it because it does a better job round-tripping the XML it's processing than other approaches I've tried, which have seemed needlessly lossy or simply misunderstand XML. XSLT is unpleasant, but I find using Oxygen makes it bearable.

That said, I'm investigating using Clojure (a lisp) to perform transformations of XML, but I haven't gotten far enough yet to know if that approach will bring me benefits.

Если вы можете использовать XSLT в декларативном стиле (хотя Я не совсем согласен с тем, что это декларативный язык), тогда я думаю, что он полезен и выразителен.

Я написал веб-приложения, которые используют объектно-ориентированный язык (C # в моем случае) для обработки уровня данных / обработки, но выводить XML, а не HTML. Затем он может быть использован клиентами напрямую как API данных или преобразован в HTML с помощью XSLT. Поскольку C # выводил XML, структурно совместимый с этим использованием, все было очень гладко, а логика представления осталась декларативной. Это было легче отслеживать и изменять, чем отправлять теги из C #.

Однако, поскольку вам требуется больше логики обработки на уровне XSLT, она становится запутанной и многословной - даже если вы «получаете» функциональный стиль.

Конечно, в наши дни я бы, вероятно, написал эти веб-приложения, используя интерфейс RESTful - и я думаю, что «языки» данных, такие как JSON, набирают обороты в тех областях, в которых XML традиционно преобразовывался с помощью XSLT. Но пока XSLT по-прежнему является важной и полезной технологией.

Да, я часто им пользуюсь. Используя разные файлы xslt, я могу использовать один и тот же источник XML для создания нескольких файлов HTML-полиглота (X) (представляющих одни и те же данные по-разному), канала RSS, канала Atom, файла дескриптора RDF и фрагмента карты сайта. .

Это не панацея. Есть что-то, что он делает хорошо, а что нет, и, как и все другие аспекты программирования, все дело в использовании правильного инструмента для правильной работы. Это инструмент, который стоит иметь в своем арсенале, но его следует использовать только тогда, когда это необходимо.

I use XSLT extensively, for a custom MVC style front-end. The model is "serialized" to xml (not via xml serializaiton), and then converted to html via xslt. The advantage over ASP.NET lie in the natural integration with XPath, and the more rigorous well-formedness requirements (it's much easier to reason about document structure in xslt than in most other languages).

Unfortunately, the language contains several limitations (for example, the ability to transform the output of another transform) which mean that it's occasionally frustrating to work with.

Nevertheless, the easily achievable, strongly enforced separation of concerns which it grants aren't something I see another technology providing right now - so for document transforms it's still something I'd recommend.

Раньше я думал, что XSLT - отличная идея. Я имею в виду, что отличная идея.

Там, где она терпит неудачу, это исполнение.

Проблема, которую я обнаружил со временем, заключалась в том, что языки программирования в XML - просто плохая идея. Это делает все это непроницаемым. В частности, я думаю, что XSLT очень сложно изучить, написать код и понять. XML поверх функциональных аспектов просто сбивает с толку. Я пытался выучить это около 5 раз за свою карьеру, и это просто не прижилось.

Хорошо, вы могли бы «использовать» его - я думаю, что отчасти это было сутью его дизайна - но это второй провал: все инструменты XSLT на рынке просто ... дерьмо!

Я должен признать здесь предвзятость, потому что зарабатываю на жизнь преподаванием XSLT. Но, возможно, стоит осветить области, в которых, как я вижу, работают мои студенты. Обычно они делятся на три группы: издательское дело, банковское дело и Интернет.

Многие из ответов на данный момент можно резюмировать следующим образом: «это не годится для творчества. веб-сайты »или« это не что иное, как язык X ». Многие технические специалисты делают карьеру, не зная функциональных / декларативных языков. Когда я преподаю, опытные специалисты по Java / VB / C / и т. Д. Испытывают проблемы с языком (например, переменные - это переменные в смысле алгебры, а не процедурного программирования). Вот многие из тех, кто здесь отвечает - я никогда не разбирался в Java, но я не собираюсь критиковать язык из-за этого.

Во многих случаях это неподходящий инструмент для создания веб-сайтов - язык программирования общего назначения может быть лучше. Мне часто приходится брать очень большие XML-документы и размещать их в сети; XSLT делает это тривиальным. Студенты, которых я вижу в этом пространстве, как правило, обрабатывают наборы данных и представляют их в Интернете. XSLT, безусловно, не единственный применимый инструмент в этой области. Однако многие из них используют для этого DOM, и XSLT, безусловно, менее болезненен.

Я вижу, что студенты-банкиры обычно используют DataPower. Это устройство XML, и оно используется, чтобы находиться между службами, «говорящими» на разных диалектах XML. Преобразование с одного языка XML на другой в XSLT почти тривиально, и количество студентов, посещающих мои курсы по этому вопросу, увеличивается.

Последний набор студентов, которых я вижу, происходят из издательского дела (как и я). Эти люди, как правило, имеют огромные документы в XML (поверьте мне, издательская отрасль все больше проникает в XML - технические публикации существуют уже много лет, а коммерческие публикации достигают этого сейчас). Эти документы должны быть обработаны (здесь на ум приходит DocBook - ePub).

Кто-то выше заметил, что скрипты обычно содержат менее 60 строк или становятся громоздкими. Если он действительно станет громоздким, скорее всего, кодировщик не совсем понял - XSLT - это мышление, которое сильно отличается от многих других языков. Если вы не настроитесь, это не сработает.

Это определенно не умирающий язык (объем работы, которую я выполняю, говорит мне об этом). Прямо сейчас он немного застрял, пока Microsoft не завершит (очень поздно) реализацию XSLT 2.

Я использовал XML, XSD и XSLT в проекте интеграции между очень непохожими системами БД где-то в 2004 году. Мне пришлось изучить XSD и XSLT с нуля, но это было несложно. Отличительной чертой этих инструментов было то, что они позволили мне писать независимый от данных код C ++, полагаясь на XSD и XSLT для проверки / проверки и последующего преобразования XML-документов. Измените формат данных, измените документы XSD и XSLT, а не код C ++, который использует библиотеки Xerces.

Для интереса: основной XSD был 150 КБ, а средний размер XSLT был <5 КБ IIRC.

Другой замечательный Преимущество заключается в том, что XSD - это документ спецификации, на котором основан XSLT. Эти двое работают в гармонии. А спецификации в наши дни в разработке программного обеспечения - редкость.

Хотя у меня не было особых проблем с изучением декларативного характера XSD и XSLT, я обнаружил, что другим программистам на C / C ++ было очень трудно приспособиться к декларативному способу. Когда они увидели это, они пробормотали процедурные вопросы, теперь, когда я понял! И они приступили (каламбур?) К написанию процедурного XSLT! Дело в том, что вам нужно изучить XPath и понять основы XML. Напоминает мне старых программистов на C, которые привыкли использовать объектно-ориентированный подход при написании C ++.

Я использовал эти инструменты, поскольку они позволили мне написать небольшую базу кода C ++, которая была изолирована от всех, кроме самых фундаментальных модификаций структур данных и последних были изменения в структуре БД. Несмотря на то, что я предпочитаю C ++ любому другому языку, я буду использовать то, что считаю полезным, чтобы обеспечить долгосрочную жизнеспособность программного проекта.

Я использовал эти инструменты, поскольку они позволили мне написать небольшую базу кода C ++, которая была изолирована от всех, кроме самых фундаментальных модификаций структур данных и последних были изменения в структуре БД. Несмотря на то, что я предпочитаю C ++ любому другому языку, я буду использовать то, что считаю полезным, чтобы обеспечить долгосрочную жизнеспособность программного проекта.

Я использовал эти инструменты, поскольку они позволили мне написать небольшую базу кода C ++, которая была изолирована от всех, кроме самых фундаментальных модификаций структур данных и последних были изменения в структуре БД. Несмотря на то, что я предпочитаю C ++ любому другому языку, я буду использовать то, что считаю полезным, чтобы обеспечить долгосрочную жизнеспособность программного проекта.

Я использовал эти инструменты, поскольку они позволили мне написать небольшую базу кода C ++, которая была изолирована от всех, кроме самых фундаментальных изменений структуры данных, и последние были изменениями структуры БД. Несмотря на то, что я предпочитаю C ++ любому другому языку, я буду использовать то, что считаю полезным, чтобы обеспечить долгосрочную жизнеспособность программного проекта.

Я использовал эти инструменты, поскольку они позволили мне написать небольшую базу кода C ++, которая была изолирована от всех, кроме самых фундаментальных изменений структуры данных, и последние были изменениями структуры БД. Несмотря на то, что я предпочитаю C ++ любому другому языку, я буду использовать то, что считаю полезным, чтобы обеспечить долгосрочную жизнеспособность программного проекта.

Мне лично нравится XSLT, и вы, возможно, захотите взглянуть на упрощенный синтаксис (без явных шаблонов, просто обычный старый файл HTML с несколькими тегами XSLT, чтобы наплевать значений), но это не для всех.

Возможно, вы просто хотите предложить своим авторам простой интерфейс Wiki или Markdown. Для этого тоже есть библиотеки, и если XSLT вам не подходит, возможно, XML не работает и для них.