我的团队一直在使用Node.js，Twitter Boostrap，Mongo DB和Mule为ESB编写仪表板应用程序。
最近，一位高管要求我们改变我们对Liferay等Portal / Portlet容器的方法。
我们团队中的一些人有Liferay的经验，我们对此有非常消极的感受。处理完整页面刷新，portlet生命周期，样式和主题问题以及有限的DBMS覆盖率等问题是我们投诉列表中的首要问题。
我们看到我们的管理团队来自哪里。他们决定让他们想要使仪表板可扩展，轻松或更容易插入其他组。
是否有一个解决方案可以平衡用户的现代Web期望与IT专业人员和负责构建和扩展应用程序的管理人员的企业需求，如Liferay？可插拔小部件在这里非常重要。
节点显然是我们偏爱Grails作为紧随其后的第二个。
谢谢，
答案 0 :(得分：0)
这个问题可能不太适合StackOverflow的格式，但我仍然可以提供一些想法。
如果您想坚持当前的平台，您需要准确确定您的高管希望从哪个功能转移到新平台。这些功能是否可以构建到当前平台中？与重写其他所有内容相比，需要花费多少精力？如何努力学习整个团队的新技能？我相信你的团队可以有效地学习新技能，但仍然需要付出努力，随着你的团队学习，会有越来越多的痛苦。如果您可以向您的管理人员展示您可以获得相同或更少工作的相同功能，并且您仍然可以拥有相似的总体拥有成本，那么您可以建立一个案例来保持当前的平台。
另外我认为你低估了Portlet容器的功能。我主要使用WebSphere Portal工作，所以也许这就是为什么我认为你提到的大多数痛点对我来说并不困难。仅仅因为您的容器需要特定的DBMS来管理自身并不意味着您不能使用单独的数据库来满足您的自定义数据需求。 JSR-286引入了serveResource作为一种使AJAX更容易在portlet中实现的方法。在WebSphere Portal中（不了解Liferay），在没有页面重新加载的情况下更改整个页面内容可能是您在列表中最难以承认的。
现代并不一定意味着尖端技术。如果您知道如何正确使用它们，大型软件产品仍然可以执行，就像任何其他工具一样。