Mon application PHP doit exporter vers différents formats XML: dois-je utiliser XSLT ou PHP natif?

Question

Mon application PHP devra pouvoir exporter (et importer depuis) ??divers formats de données, principalement basés sur XML.

J'ai l'option de

• En PHP, utilisez DOM pour exporter dans un format XML qui est un sur-ensemble de toutes les données nécessaires aux autres, et créez une feuille de style XSLT distincte pour chaque format de sortie que je souhaite prendre en charge, en exécutant la sortie DOM via XSL de PHP. extension.

ou

• N'utilise pas l'extension XSL de PHP, mais implémente chaque format de sortie en tant que classe en PHP natif qui se traduit directement à partir des objets / structures internes vers un format XML donné à l'aide de DOM, chacune de ces classes implémentant la même interface afin qu'elles soient interchangeables.

L'application sera utilisée par les universités et est un outil qui gère les enregistrements de personnes de différentes manières, ainsi que les importations / exportations de diverses sources telles que leur système de ressources humaines, etc. Je vais implémenter l'ensemble des formats d'entrée et de sortie. moi-même, mais à l'avenir, il est possible que quelqu'un l'utilisant veuille le modifier pour prendre en charge son propre format.

Une des raisons pour lesquelles je n’envisage PAS d’utiliser XSLT est que si quelqu'un d'autre maintient l'application à l'avenir, à part moi, il semble que très peu de personnes connaissent même XSLT - beaucoup plus de personnes semblent connaître PHP.

Une autre solution est que la seconde solution semble plus efficace et plus "programmée", et plus flexible en ce sens que je serais capable de générer et d'importer tout aussi facilement des formats non XML tels que CSV ou du texte basé sur des colonnes. en surchargeant les éléments nécessaires de la classe, sans que cela soit souvent nécessaire.

Une troisième raison, mais très petite et insignifiante, est que PHP a besoin d'une recompilation pour activer XSL alors que DOM est activé par défaut, ce qui le rendrait donc un peu plus portable. Cependant, ce n’est pas un problème car il est facile de reconfigurer PHP.

Que pensez-vous de mon raisonnement?

Answer 1

Mon opinion personnelle est que votre décision devrait être fortement basée sur le fait que vous jugeriez la connaissance XSLT de votre public cible. S'il est clair que XSLT est en quelque sorte "terra incognita" parmi les personnes qui doivent travailler avec le système (y compris vous-même), vous pouvez exclure la solution XSLT. La nécessité et les efforts nécessaires pour apprendre XSLT nieront les avantages (très élégant - en particulier lors de la conversion de XML en XML, pas besoin de jouer avec du code PHP, aucune connaissance de PHP requise) que vous obtiendrez de la solution XSLT.

Peut-être qu'une solution à double sens pourrait être la bonne chose à faire. Vous pouvez créer un système d'adaptateur pour l'importation et l'exportation qui utilise XSLT pour les formats de données XML et permet d'utiliser du code PHP pour tous les formats de données qui ne sont pas basés sur XML. Ainsi, chaque développeur peut choisir la manière avec laquelle il est le plus à l'aise.

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

Je pense que votre raisonnement est sain et que c'est ainsi que je voudrais aller.

En gros, vous parlez de classes pont / adaptateur / façade. Ils sont (à mon sens) plus souples et plus faciles à comprendre que les modèles XSL.

La troisième raison n'en est pas une, car la prise en charge de XSL ne nécessite rien de plus que de supprimer une extension PHP.

Je suis également ravi de voir que vous souhaitez le faire via les extensions DOM (ou une bibliothèque équivalente) plutôt que d'écrire XML sous forme de texte, ce qui introduit tous les problèmes évidents et vous permettra d'éviter ce qui vous échappe.

Personnellement, je pense aussi que les modèles XSL sont plus fragiles au changement (du fait qu’ils sont un peu plus cryptiques pour la grande majorité des programmeurs), donc si le format de votre sur-ensemble change (ce qui, admettons-le, vous le ferez), vous ' Vous devrez éventuellement modifier tous vos modèles. Bien sûr, vous devrez peut-être aussi le faire avec du code, mais le code sera probablement plus facile à gérer.

Answer 3

Problème intéressant.

Les deux solutions fonctionneront, mais vous le savez certainement, je suppose.

Je choisirais probablement la solution codée moi-même. Mais c’est probablement parce que XSLT me donne mal à la tête.

Il existe un avantage à XSLT: vous pouvez demander qu’ils soient produits par les personnes qui vous fournissent le code XML non modifié.

Si vous les produisez toujours, cela n'a probablement pas d'importance et la solution codée sera plus facile à gérer la plupart du temps.