Моему приложению PHP необходимо экспортировать в различные форматы XML: должен ли я использовать XSLT или собственный PHP? - PullRequest
Новая
       11

Моему приложению PHP необходимо экспортировать в различные форматы XML: должен ли я использовать XSLT или собственный PHP?

2 голосов
/ 04 мая 2009

Мое PHP-приложение должно иметь возможность экспортировать (и импортировать) ряд различных форматов данных, в основном на основе XML.

У меня есть опция

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

или

  • Не использует расширение XSL в PHP, но реализует каждый выходной формат как класс в нативном PHP, который переводит напрямую из внутренних объектов / структур в заданный формат XML с использованием DOM, причем каждый такой класс реализует один и тот же интерфейс, поэтому они взаимозаменяемы.

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

Одна из причин, по которой я рассматриваю НЕ использовать XSLT, заключается в том, что если кто-то еще будет поддерживать приложение в будущем, кроме меня, то, похоже, очень немногие люди даже знают XSLT - гораздо больше людей знают PHP.

Другое - то, что второе выглядит как более эффективное и «программируемое» решение, и более гибкое в том смысле, что я мог бы так же легко выводить и импортировать из не XML-форматов, таких как CSV или текст на основе столбцов перегружая необходимые части класса, а не то, что часто будет необходимо.

Третья, но очень малая и незначительная причина заключается в том, что PHP требуется перекомпиляция для включения XSL, тогда как DOM включен по умолчанию, поэтому он будет немного более переносимым. Однако это не является большой проблемой, так как легко перенастроить PHP.

Что вы думаете о моих рассуждениях?

Ответы [ 3 ]

4 голосов
/ 04 мая 2009

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

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

interface My_DataConverter_Interface
{
    /**
          * @param string                $file
          * @return My_DataObject
          */
    function import($file);

    /**
          * @param My_DataObject $data
          * @param string                $file
          */
    function export(My_DataObject $data, $file);
}

abstract class My_DataConverter_Xslt implements My_DataConverter_Interface
{ /* ... */ }

class My_DataConverter_XmlFormat1 extends My_DataConverter_Xslt
{ /* ... */ }

class My_DataConverter_XmlFormat2 extends My_DataConverter_Xslt
{ /* ... */ }

class My_DataConverter_Csv implements My_DataConverter_Interface
{ /* ... */ }
3 голосов
/ 04 мая 2009

Я думаю, что ваши рассуждения верны, и я тоже так поступил.

В основном вы говорите о классах моста / адаптера / фасада. Они (imho) более гибкие и понятные, чем шаблоны XSL.

Третья причина на самом деле не одна, потому что поддержка XSL включает не что иное, как раскомментирование расширения PHP.

Я также рад видеть, что вы хотите сделать это с помощью расширений DOM (или эквивалентной библиотеки), а не писать XML в виде текста, который вводит все проблемы с выходом и все, что вы избежите на своем пути.

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

2 голосов
/ 04 мая 2009

Интересная проблема.

Оба решения будут работать, я думаю, вы это знаете.

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

У XSLT есть свои плюсы, и вы можете попросить, чтобы их изготовили люди, давшие вам неизмененный XML.

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

...