Liferay/JSR 168 和 286 门户的替代方案？

Question

我的团队一直在使用 Node.js、Twitter Boostrap、Mongo DB 和 Mule 为 ESB 编写仪表板应用程序。

最近一位高管要求我们改变对像 Liferay 这样的 Portal/Portlet 容器的方法。

我们团队中的一些人有使用 Liferay 的经验，我们对此有相当负面的感受。处理整页刷新、portlet 生命周期、样式和主题问题以及有限的 DBMS 覆盖等问题是我们抱怨的首要问题。

我们看到了我们的执行团队来自哪里。他们决定要使仪表板可扩展且易于或更易于插入到其他组中。

是否有一种解决方案可以平衡用户对现代 Web 的期望与关注构建和可扩展应用程序（如 Liferay）的 IT 专业人员和管理人员的企业需求？可插拔小部件在这里很重要。

Node 显然是我们的首选，Grails 之类的东西紧随其后。

谢谢，

Answer 1

这个问题可能不太适合 * 的格式，但我仍然可以提供一些想法。

如果您想继续使用当前平台，您需要准确了解您的高管希望从迁移到新平台中获得哪些功能。您可以在当前平台中构建这些功能吗？与重写其他所有内容相比，这需要多少努力？在整个团队中学习一项新技能需要付出多大的努力？我确信您的团队可以有效地学习新技能，但这仍然需要努力，并且随着您的团队学习，会有成长的痛苦。如果您可以向您的主管证明您可以以相似或更少的努力获得相同的功能，并且您仍然可以拥有相似的总拥有成本，那么您可以提出继续使用当前平台的理由。

另外，我认为您低估了 Portlet 容器的功能。我主要使用 WebSphere Portal 工作，所以也许这就是为什么我认为您提到的大多数痛点对我来说并不难管理。仅仅因为您的容器需要特定的 DBMS 来管理自身并不意味着您不能使用单独的 DB 来满足您的自定义数据需求。 JSR-286 引入了 serveResource 作为一种使 AJAX 更容易在 portlet 中实现的方法。在 WebSphere Portal 中（不了解 Liferay），在不重新加载页面的情况下更改整个页面内容可能是您列表中最困难的，但我承认。

现代并不一定意味着尖端技术。如果您知道如何正确使用大型软件产品，它们仍然可以发挥作用，就像任何其他工具一样。