我的團隊一直在使用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