La mia app PHP deve esportare in una gamma di diversi formati XML: dovrei usare XSLT o PHP nativo?

Question

La mia applicazione PHP dovrà essere in grado di esportare (e importare da) una gamma di diversi formati di dati, principalmente basati su XML.

Ho l'opzione di

• In PHP, usa DOM per esportare in un formato basato su XML che è un superset di tutti i dati necessari agli altri e crea un foglio di stile XSLT separato per ogni formato di output che voglio supportare, eseguendo l'output DOM attraverso l'XSL di PHP estensione.

o

• Non usando l'estensione XSL di PHP, ma implementando ogni formato di output come una classe in PHP nativo che si traduce direttamente dagli oggetti / strutture interni in un determinato formato XML utilizzando DOM, ciascuna di tali classi implementa la stessa interfaccia in modo che siano intercambiabili.

L'app verrà utilizzata dalle università ed è uno strumento che gestisce i record di "persone" in vari modi e le importazioni / esportazioni da varie fonti come il loro sistema di risorse umane, ecc. Implementerò il set di formati di input e output me stesso, ma in futuro c'è la possibilità che qualcuno che lo utilizza voglia modificarlo per supportare il proprio formato.

Uno dei motivi per cui sto considerando di NON utilizzare XSLT è che se qualcun altro manterrà l'app in futuro diverso da me, sembra che pochissime persone conoscano XSLT, molte più persone sembrano conoscere PHP. p>

Un altro è che il secondo sembra una soluzione più efficiente e "programmativa", e più flessibile, nel senso che sarei in grado di produrre e importare da formati non XML come CSV o testo basato su colonne altrettanto facilmente sovraccaricando le parti necessarie della classe, non che ciò sarebbe spesso necessario.

Un terzo, ma molto piccolo e insignificante motivo è che PHP deve essere ricompilato per abilitare XSL mentre DOM è abilitato di default, quindi sarebbe un po 'più portatile. Tuttavia questo non è un grosso problema in quanto è facile riconfigurare PHP.

Cosa ne pensi del mio ragionamento?

Answer 1

La mia opinione personale è che la tua decisione dovrebbe essere fortemente basata sul fatto che giudicheresti le conoscenze XSLT nel tuo pubblico previsto. Se è chiaro che XSLT è in qualche modo "terra incognita" tra le persone che devono lavorare con il sistema (incluso te stesso), puoi escludere la soluzione XSLT. La necessità e lo sforzo di apprendere XSLT annulleranno i vantaggi (molto eleganti, specialmente quando si trasforma XML in XML, non c'è bisogno di confondere con il codice PHP, non è necessaria alcuna conoscenza di PHP) che otterrai dalla soluzione XSLT.

Forse una soluzione a due vie potrebbe essere la cosa giusta da percorrere. È possibile creare un sistema adattatore per l'importazione e l'esportazione che utilizza XSLT per i formati di dati XML e offre la possibilità di utilizzare il codice PHP per tutti i formati di dati che non sono basati su XML. In questo modo ogni sviluppatore può scegliere il modo in cui è più a suo agio.

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

Penso che il tuo ragionamento sia corretto ed è anche il modo in cui vorrei andare.

Fondamentalmente quello di cui stai parlando sono le classi bridge / adapter / facade. Sono (imho) più flessibili e più facili da comprendere rispetto ai modelli XSL.

Il terzo motivo non è proprio uno perché il supporto XSL non implica nient'altro che decommentare un'estensione PHP.

Sono anche felice di vedere che vuoi farlo tramite le estensioni DOM (o una libreria equivalente) piuttosto che scrivere XML come testo, il che introduce tutti i problemi di fuga e quant'altro ti eviterai.

Personalmente penso anche che i modelli XSL siano più fragili da cambiare (in virtù del fatto che sono un po 'più criptici per la stragrande maggioranza dei programmatori), quindi se il tuo formato superset cambia (il che, ammettiamolo, lo farà) Potenzialmente dovrai cambiare tutti i tuoi modelli. Ovviamente potresti doverlo fare anche con il codice, ma il codice sarà probabilmente più facile da mantenere.

Answer 3

Problema interessante.

Entrambe le soluzioni funzioneranno, immagino lo sappiate comunque.

Probabilmente andrei anch'io con la soluzione codificata. Ma probabilmente ha a che fare con XSLT che mi fa venire il mal di testa.

C'è un lato positivo di XSLT ed è che puoi chiedere che vengano prodotti dalle persone che ti danno l'XML inalterato.

Se li produrrete sempre, probabilmente non importa e la soluzione codificata sarà più facile da mantenere per la maggior parte del tempo.