这不是一个技术问题。我所做的是创建了一个我想在 Liferay portlet 中使用的 Ext JS 应用程序。在尝试将整个 Ext JS 项目导入 Liferay 并失败后，我决定将整个应用程序放在 iframe 中，并将 iframe 轻松放入我的 portlet 中（因为 portlet 可以呈现 html）。
这可能是最简单的方法，它使我的项目体积更小（不导入大约 204MB 的整个 Ext JS 框架以及我的应用程序）。
此外，它允许可扩展性。每当我修改我的 Ext JS 应用程序时，更改将立即显示在我的 portlet 中，因为 iframe 独立于主 html 文档。
问题：这样做有没有我忽略的问题？可能出现的任何问题？
对我来说，这似乎是一种简单的方法，但当我想到它时，它是一种更聪明的方法。
加油伙伴们！
你提供了一些关于你做出的决定的信息，但不是关于他们的理由。我正在推断一些可能的原因来强调这种方法可能存在的警告：
假设您必须与 Liferay 集成，因为这是现有的门户，而您选择 Ext JS 是因为这是您最熟悉的。
这通过充分利用您的时间来优化应用程序的开发时间。如果您是办公室里的 Ext JS 专家，这可能是维护人员的负担。如果 Ext JS 只是“个人”选择的一个示例，那么您的门户最终可能会成为一大堆“遗留”实现（我称之为此类解决方案）。因此，您可以从未来的维护工作中获得快速的开发时间。
假设您已选择使用 Ext JS（portlet 外部），因为您的团队中没有人可以提示您如何进行正确的门户/portlet 开发。这应该为团队提出一个危险信号，无法支持选择的环境。但是可以通过选择不同的平台或通过适当的培训来减轻它
假设您选择了 Ext JS，因为没有人关心它，它是一个真正的“一次性”应用程序，一次写入，永久运行（或在有限时间内运行），没有人期望任何维护工作，而您只是想要它偏僻。在这种情况下：别担心。
你缺少什么？您基本上不会从门户环境中获得任何东西：基础设施、主题、身份管理、许可、集群、故障转移、缓存、监控等。这是否可以接受由您来判断。一些示例：现在是否需要管理员监控您独立运行的应用程序，因为它可以独立于门户而关闭？谁知道万一出现故障该怎么办？您如何处理登录到您的应用程序？
这听起来不像您在使用 Liferay 或 portlet，因为它们是典型的。这就提出了一个问题，您为什么要开始使用 Liferay 和 portlet？如果你只是在编写一个 JS 应用程序，那么在中间添加一个你不知道如何使用的额外层有什么意义呢？我并不是说这是一种侮辱，只是看起来它不是适合这项工作的工具，或者您需要花更多时间了解 Liferay、portlet 以及它们的工作原理。
更多关于您的具体问题：一般来说，我倾向于将 iframe 的使用视为试图找到更好的解决方案的一种技巧。iframe 有一些用例。看到这个问题为什么人们仍然使用 iframe？有关 iframe 用例的更多信息。
编辑：多考虑一下为什么我觉得这个解决方案不如它可能的那么好。通过 Liferay 提供的 iframe 为您的应用程序提供服务，您可以更改解决方案的架构。我以前在 portlet 中使用过 iframe，因此它可以提供解决方案。但我们这样做只是因为没有其他方法可以将我们需要的功能纳入我们的解决方案。这是因为这是我们必须连接的服务的限制。通过让 Liferay 为应用程序提供服务，您可以维护现有解决方案的一般架构。