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

Question

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

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

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

我们知道我们的执行团队来自哪里。他们决定要使仪表板具有可扩展性，并且更容易或更容易插入到其他组中。

有没有一种解决方案可以平衡用户对现代web的期望和IT专业人员和高管的企业需求，他们关心的是使用Liferay这样的东西构建和扩展应用程序？可插拔的小部件在这里很重要。

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

谢谢,

Answer 1

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

如果你想坚持当前的平台，你需要准确地计算出你的管理人员希望从迁移到新平台中获得什么功能。这些特性可以构建到您当前的平台中吗？与重写其他一切相比，这需要多大的努力？在整个团队中学习一项新技能需要付出多大的努力？我相信你的团队可以有效地学习新技能，但这仍然需要努力，在你的团队学习的过程中会有成长的痛苦。如果您能够向您的高管表明，您可以以类似或更少的努力获得相同的功能，并且您仍然可以拥有类似的总拥有成本，那么您就有理由留在当前的平台上。

另外，我认为您低估了Portlet容器的功能。我主要使用WebSphere门户网站，所以也许这就是为什么我认为你提到的大多数痛点对我来说并不难管理。仅仅因为您的容器需要一个特定的DBMS来管理自己，并不意味着您不能使用单独的DB来满足您的自定义数据需求。引入serveResource是为了使AJAX更容易在portlets中实现。在WebSphere门户(不了解Liferay)中，在不重新加载页面的情况下更改整个页面内容可能是您列表中最困难的部分。

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