当前位置：文江博客话题详情

我的 PHP 应用程序需要导出为一系列不同的 XML 格式：我应该使用 XSLT 还是本机 PHP？

发布于 2024-07-20 01:25:24 字数 748 浏览 2 评论 0原文

我的 PHP 应用程序需要能够导出（和导入）一系列不同的数据格式，主要是基于 XML 的。

我可以选择

在 PHP 中，使用 DOM 导出到某种基于 XML 的格式，该格式是其他格式所需的所有数据的超集，并为我想要支持的每种输出格式创建一个单独的 XSLT 样式表，通过运行 DOM 输出PHP 的 XSL 扩展。

或者

不使用 PHP 的 XSL 扩展，而是将每种输出格式实现为本机 PHP 中的一个类，该类使用 DOM 直接从内部对象/结构转换为给定的 XML 格式，每个此类都实现相同的接口，因此它们可以互换。

该应用程序将由大学使用，是一种以各种方式管理“人员”记录以及从各种来源（例如人力资源系统等）导入/导出的工具。我将自己实现一组输入和输出格式，但是将来，使用它的人可能会想要修改它以支持他们自己的格式。

我考虑不使用 XSLT 的原因之一是，如果将来除了我之外还有其他人维护该应用程序，似乎很少有人知道 XSLT - 似乎有更多的人知道 PHP。

另一个是，第二个似乎是一个更高效和“编程”的解决方案，并且更灵活，因为我可以通过重载来轻松地输出和导入非 XML 格式（如 CSV 或基于列的文本）课堂上必要的部分，但并不经常是必要的。

第三个但非常小且无关紧要的原因是 PHP 需要重新编译才能启用 XSL，而 DOM 默认情况下启用，因此它会更便携一些。不过，这并不是什么大问题，因为重新配置 PHP 很容易。

你觉得我的推理怎么样？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

妄司 2024-07-27 01:25:24

我个人的观点是，您的决定应该主要基于您如何判断目标受众的 XSLT 知识这一事实。如果很明显 XSLT 在必须使用该系统的人员（包括您自己）中某种程度上是“未知领域”，那么您可以排除 XSLT 解决方案。学习 XSLT 的需要和努力将抵消您从 XSLT 解决方案中获得的优势（非常优雅 - 特别是在将 XML 转换为 XML 时，无需弄乱 PHP 代码，无需 PHP 知识）。

也许双向解决方案可能是正确的选择。您可以构建一个用于导入和导出的适配器系统，该系统将 XSLT 用于 XML 数据格式，并提供对所有不基于 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
{ /* ... */ }

My personal opinion is that your decision should be based strongly on the fact how you'd judge the XSLT knowledge in your intended audience. If it's clear that XSLT is somehow "terra incognita" among the people having to work with the system (that includes yourself), you can rule out the XSLT-solution. The need and the effort to learn XSLT will negate the advantages (very elegant - especially when transforming XML to XML, no need to mess with PHP code, no PHP knowledge needed) you'll get from the XSLT-solution.

Perhaps a two-way solution could be the right thing to go with. You could build an adapter-system for importing and exporting that uses XSLT for the XML data formats and provides the ability to use PHP code for all the data formats that aren't XML based. This way every developer can choose the way he's more comfortable with.

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

回复收藏 0 原文