apache-tiles - Apache Tiles 框架的优缺点

Question

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

Answer 1

（类似于这个）

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

这不是真的。还有一个关于瓷砖的普遍挥之不去的误解。

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

这里有一个教程可以帮助你

• 弹簧到瓷砖集成，
• 带有通配符的定义，
• 使用 OptionsRenderer 实现回退模式，以及
• 定义组成。

Answer 2

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

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

• 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 项目有一些活动，但绝对不如 ThymeLeaf 充满活力

总结 -优点：

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

缺点：

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

Answer 3

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