私のPHPアプリは、さまざまなXML形式にエクスポートする必要があります。XSLTまたはネイティブPHPを使用する必要がありますか？

StackOverflow https://stackoverflow.com/questions/818679

  •  03-07-2019
  •  | 
  •  

質問

私のPHPアプリケーションは、主にXMLベースのさまざまなデータ形式にエクスポート（およびインポート）できる必要があります。

オプションがあります

  • PHPでは、DOMを使用して、他のユーザーが必要とするすべてのデータのスーパーセットであるXMLベースの形式にエクスポートし、サポートする出力形式ごとに個別のXSLTスタイルシートを作成し、PHPのXSLを介してDOM出力を実行します拡張子。

または

  • PHPのXSL拡張機能を使用せず、DOMを使用して内部オブジェクト/構造から特定のXML形式に直接変換するネイティブPHPの各出力形式をクラスとして実装します。各クラスは同じインターフェースを実装しているため、交換可能です。

このアプリは大学で使用され、「人」レコードをさまざまな方法で管理し、HRシステムなどのさまざまなソースからのインポート/エクスポートを行うツールです。一連の入出力フォーマットを実装します私自身ですが、将来的にはそれを使用している人が自分のフォーマットをサポートするためにそれを変更したいと思う可能性があります。

XSLTを使用しないことを検討している理由の1つは、他の誰かが自分以外でアプリを将来メンテナンスしようとする場合、XSLTを知っている人はほとんどいないようです。 p>

もう1つは、2番目の方法はより効率的で「プログラマー」なソリューションのように見え、CSVや列ベースのテキストなどの非XML形式で簡単に出力およびインポートできるという意味でより柔軟ですクラスの必要な部分をオーバーロードすることにより、それがしばしば必要になることではありません。

第三の、しかし非常に小さくて取るに足らない理由は、PHPがXSLを有効にするために再コンパイルを必要とするのに対し、DOMはデフォルトで有効になっているためです。ただし、PHPを簡単に再構成できるため、これはそれほど大きな問題ではありません。

私の推論についてどう思いますか？

役に立ちましたか？

解決

個人的な意見では、あなたの決定は、対象読者のXSLT知識をどのように判断するかという事実に強く基づいているべきだと思います。 XSLTが「テラインコグニータ」であることが明らかな場合は、システム（自分自身を含む）で作業しなければならない人々の中で、XSLTソリューションを除外できます。 XSLTを学習する必要性と努力は、XSLTソリューションから得られる利点（特に、XMLをXMLに変換する場合、PHPコードを台無しにする必要がない、PHPの知識が必要ない場合）を無効にします。

おそらく、双方向の解決策が適切である可能性があります。 XMLデータ形式にXSLTを使用し、XMLベースではないすべてのデータ形式にPHPコードを使用する機能を提供する、インポートおよびエクスポート用のアダプターシステムを構築できます。このようにして、すべての開発者がより快適な方法を選択できます。

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

他のヒント

あなたの推論は健全だと思いますし、それは私が行く方法でもあります。

基本的にあなたが話しているのはbridge / adapter / facadeクラスです。 XSLテンプレートよりも（imho）より柔軟で理解しやすいです。

XSLのサポートにはPHP拡張機能のコメントを外すことしか含まれないため、3番目の理由は実際には1つではありません。

また、XMLをテキストとして記述するのではなく、DOM拡張機能（または同等のライブラリ）を介してこれを実行したいと思うことも嬉しく思います。これにより、すべてのエスケープの問題と回避方法が紹介されます。

個人的には、XSLテンプレートは変更するのがより脆弱だと思います（大多数のプログラマにとってはやや難解です）ので、スーパーセット形式が変更されたら潜在的にすべてのテンプレートを変更する必要があります。もちろん、コードでもこれを行う必要がありますが、コードはおそらく保守が容易になります。

興味深い問題。

両方のソリューションが機能しますが、これを知っていると思います。

私はおそらく自分でコード化されたソリューションを使用するでしょう。しかし、それはおそらくXSLTが頭痛の種になっているからです。

XSLTには利点があります。それは、変更されていないXMLを提供してくれる人がXSLTを作成するように依頼できることです。

常にそれらを作成するのであれば、それはおそらく重要ではなく、コード化されたソリューションはほとんどの場合維持しやすいでしょう。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top