Apache Tiles 框架的优缺点

Question

今天的问候，我只是想找出使用​​Apache Tiles 框架的利弊。请让我知道您对此的宝贵建议、cmets 和意见。

Answer 1

（类似于this）

使用 Tiles，似乎当我有 100 个操作时，我需要创建 100 个 jsp 文件并在 tiles.xml 中创建 100 个定义 - 不幸的是，是的

这不是真的。还有一个关于瓷砖的常见误解。

这样的样板配置是从 tile-1 天开始的。当引入通配符时，对于tiles-2 确实没有必要，尤其是对于tiles-3 和OptionsRenderer。

这里有一个tutorial 可以帮助你

• spring to tile 集成，
• 带有通配符的定义，
• 使用 OptionsRenderer 实现回退模式，以及
• 定义组合。

Answer 2

我一直在将 Apache Tiles 用于一个非商业项目，但每周我对它的热情都在降低。但这可能是由于非常基本的文档、太少的示例（并且没有关于高级主题的示例）和相当小的社区造成的。

此外，我建议您查看这些资源：

• Better alternative to Apache Tiles - 使用 Tiles，似乎当我有 100 个操作时，我需要创建 100 个 jsp 文件并在 tiles.xml 中创建 100 个定义 - 是的，不幸的是

• http://blog.springsource.org/2012/10/30/spring-mvc-from-jsp-and-tiles-to-thymeleaf/ - Apache Tiles 方法类似于自定义标签，因此具有相同的优缺点。 Apache Tiles 项目有一些活动，但肯定不如 ThymLeaf 充满活力

总结一下——优点：

• 能够在基本视图之外构建复杂 (composite) 视图，UI 重用
• 它已经存在了一段时间，并且在一些主要框架中得到了支持，例如 Spring（它很容易上手）

缺点：

• 小社区，不太活跃恕我直言
• 基本文档、少量示例、难以在网络上找到有价值的最新资源 - 您将不得不一直深入研究 Java 接口和类以查找 apache tile 提供的内容
• composite view 而不是 decorator - 我个人认为装饰器模式更灵活 - 您可以在请求处理的最后定义变量、槽、属性等，而在 composite view 中您需要专注于当您定义属性时（子视图的所有属性都必须在渲染之前定义 - 属性覆盖更困难）

Answer 3

我已经使用瓷砖很长一段时间了，我必须说，一旦你开始使用它，你就会知道你会喜欢它的所有功能。一开始它看起来如此复杂和繁琐，你会花很多时间在谷歌上搜索。但在那之后，您将利用在其他框架或概念中找不到的大量强大功能，例如模板继承、覆盖、灵活组合、通配符视图匹配、视图准备器等......并且它与 Spring 集成得非常好。 另一方面，到目前为止我唯一想念的功能是无法直接在视图中定义父模板（这实际上会破坏 Tiles 概念）。