Mi aplicación PHP necesita exportar a una variedad de formatos XML diferentes: ¿debo usar XSLT o PHP nativo?

Question

Mi aplicación PHP deberá poder exportar (e importar) desde una gama de diferentes formatos de datos, en su mayoría basados ??en XML.

Tengo la opción de

• En PHP, use DOM para exportar a algún formato basado en XML que es un superconjunto de todos los datos que necesitan los demás, y cree una hoja de estilo XSLT separada para cada formato de salida que quiera admitir, ejecutando la salida DOM a través del XSL de PHP extensión.

o

• No usa la extensión XSL de PHP, pero implementa cada formato de salida como una clase en PHP nativo que se traduce directamente desde los objetos / estructuras internas a un formato XML dado usando DOM, y cada clase implementa la misma interfaz para que sean intercambiables.

La aplicación será utilizada por las universidades y es una herramienta que gestiona los registros de "personas" de varias maneras, e importa / exporta de diversas fuentes como su sistema de recursos humanos, etc. Estaré implementando el conjunto de formatos de entrada y salida. yo mismo, pero en el futuro existe la posibilidad de que alguien que lo use desee modificarlo para que sea compatible con su propio formato.

Una razón por la que estoy considerando NO usar XSLT es que, si alguien más va a mantener la aplicación en un futuro que no sea yo, parece que muy pocas personas saben que XSLT, mucha más gente parece saber PHP.

Otra es que la segunda parece ser una solución más eficiente y "programada", y más flexible en el sentido de que podría enviar e importar desde formatos no XML como CSV o texto basado en columnas con la misma facilidad. al sobrecargar las partes necesarias de la clase, no es que a menudo eso sea necesario.

Una tercera razón, pero muy pequeña e insignificante, es que PHP necesita volver a compilar para habilitar XSL, mientras que DOM está habilitado de forma predeterminada, por lo que sería un poco más portátil. Sin embargo, esto no es un gran problema ya que es fácil reconfigurar PHP.

¿Qué piensas de mi razonamiento?

Answer 1

Mi opinión personal es que su decisión debe basarse firmemente en el hecho de cómo juzgaría el conocimiento de XSLT en su audiencia prevista. Si está claro que XSLT es de alguna manera " terra incognita " Entre las personas que tienen que trabajar con el sistema (que se incluye a usted mismo), puede descartar la solución XSLT. La necesidad y el esfuerzo de aprender XSLT anularán las ventajas (muy elegantes, especialmente al transformar XML en XML, no hay necesidad de meterse con el código PHP, no se necesita conocimiento de PHP) que obtendrá de la solución XSLT.

Quizás una solución bidireccional podría ser la solución correcta. Podría crear un sistema de adaptadores para la importación y exportación que utilice XSLT para los formatos de datos XML y ofrezca la capacidad de usar el código PHP para todos los formatos de datos que no estén basados ??en XML. De esta manera, cada desarrollador puede elegir la forma en que se sienta más cómodo.

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
{ /* ... */ }

Answer 2

Creo que tu razonamiento es sólido y es la forma en que yo también lo haría.

Básicamente, lo que estás hablando son clases de puente / adaptador / fachada. Son (imho) más flexibles y fáciles de entender que las plantillas XSL.

La tercera razón no es realmente una porque el soporte XSL no implica nada más que descomentar una extensión de PHP.

También me alegra ver que quieres hacer esto a través de las extensiones DOM (o biblioteca equivalente) en lugar de escribir XML como texto, que introduce todos los problemas de escape y todo lo demás evitarás tu camino.

Personalmente, también creo que las plantillas XSL son más frágiles de cambiar (en virtud de que son algo más crípticas para la gran mayoría de los programadores), por lo que si el formato de superconjunto cambia (lo cual, seamos sinceros, lo haremos) usted " Es posible que necesites cambiar todas tus plantillas. Por supuesto, es posible que también tenga que hacer esto con el código, pero es probable que el código sea más fácil de mantener.

Answer 3

Problema interesante.

Ambas soluciones funcionarán, supongo que sabes esto sin embargo.

Probablemente yo mismo iría con la solución codificada. Pero probablemente eso tenga que ver con que XSLT me da dolor de cabeza.

XSLT tiene un aspecto positivo y es que puede solicitar que las personas que lo produzcan lo produzcan.

Si siempre va a producirlos, probablemente no importa y la solución codificada será más fácil de mantener la mayor parte del tiempo.