我的团队一直在使用Node.js,Twitter Boostrap,Mongo DB和Mule为ESB编写仪表板应用程序。替代Liferay/JSR 168和286门户?
最近有一位高管要求我们将我们的方法改为像Liferay这样的Portal/Portlet容器。
我们团队中的一些人有Liferay的经验,对此我们有非常消极的感受。处理完整页面刷新,portlet生命周期,样式和主题问题以及有限的DBMS覆盖范围是我们的投诉列表中的头等大事。
我们看到我们的执行团队来自哪里。他们决定,他们希望使仪表板可扩展,易于或容易插入其他组。
有没有一种解决方案能够平衡用户的现代网络期望与IT专业人员和高管关心构建和扩展应用程序的企业需求?可插入的小部件在这里很重要。
节点显然会成为我们的首选,像Grails这样的东西将成为我们的首选。
感谢,
门户解决了与grails不同的问题 - 例如,它提供了更多的基础设施,如用户和页面管理等。我不明白“有限的DBMS覆盖率”是什么意思,因为您的portlet可以使用您想要的任何数据库。此外,整页请求很容易克服:您选择的UI库可以自动完成,也可以手动完成。到目前为止,我没有看到你带来的消极论点的消极影响 - 除了“Liferay不在你的喜好列表中”。 – 2013-03-19 23:00:56
感谢您的反馈。澄清更多。我可以使用grails实现类似于门户网站的规范吗?它有一个丰富的插件库,我想还有其他人不喜欢Liferay。为此我发布了问题。我想解决Liferay解决同样的问题,而不需要Portal的开销。此外,如果您有一些很好的例子可以解决整页请求,那将是一个很好的帮助。也许我正在以错误的方式看待Portal--这是旧规格/旧技术。我主要关注如何在满足管理人员的同时提供良好的用户体验 – binarygiant 2013-03-20 00:17:44
我会说门户网站是一个超载的词汇。您可以“轻松”将新的JS方法和您的堆栈与Liferay提供的基础结构合并。无论哪种方式,Liferay现在都朝OSGi捆绑包的方向发展,这些捆绑包只是某种应用的包装(可以是从AlngularJS到旧式JSP基础的任何东西)。特别是在继续将基于JS的应用程序作为一等公民时,还有很多工作要做。挖掘,不要被旧的技术水平吓倒。无论哪种方式,它不再是一个门户网站,而是一个数字体验平台:D – 2017-09-25 08:07:46