我目前正在研究Flex和Liferay提供的RIA。我们正在取代在内部AJAX / Java库上构建的相当大的现有应用程序。为此,Flex似乎满足了我们的开发需求,但我们已经投入了一把扳手。我们需要与Liferay和JSF构建的另一个内部应用程序集成。
在调查Liferay之后,我不相信它为我们现有的应用程序带来任何好处,因为通过portlet传递除了实现与其他应用程序的集成之外似乎没有任何固有的好处。它似乎也有许多缺点,包括swf与页面其余部分之间的平滑交互,陷入Liferay的用户管理以及缺乏面向开发人员的文档。
在我看来Liferay是一个很好的解决方案,如果你需要一个内部wiki /新闻/社交应用程序,但是为了提供强大的RIA,我们似乎正试图在一个圆孔中安装一个方形钉。
我的问题是:Liferay用于提供完整的RIA应用程序,还是更适合提供小型应用程序的平台?我错过了关于Liferay的一些东西,这使它非常适合RIA吗?
提前感谢任何建议!
答案 0 :(得分:0)
您可以轻松地将Flex应用程序显示在门户网站(Liferay或其他)中,但以下是您可能遇到的一些问题:
1)典型的门户服务器保存服务器上的所有状态 - 对于所有portlet。每次交互都会导致页面刷新,这会根据服务器端状态重新呈现页面上的所有内容。对于Flex应用程序,通常不需要服务器上的状态。并且您不希望每次交互都重新加载Flex应用程序。一些门户网站正在获得更多Ajax'y,这解决了部分问题,但在HTML portlet或门户网站chrome中总会有一些交互导致页面刷新。这意味着Flex应用程序必须完成一些工作才能在页面刷新之后保持状态。一个简单的方法是使用LSO,但这需要大量额外的管道代码。
2)Portlet间通信(在JSR 168门户中)基于页面刷新通过服务器。这也适用于Flex应用程序。 JSR 286正试图解决这个问题以支持Ajax portlet IPC。在此之前使Flex应用程序与标准IPC协同工作很困难(但可能)。
3)门户网站的很大一部分是权利,自定义和首选项。这些都很难使用并与Flex交互。在JSR 168门户中,没有一种标准的方法可以做到这一点。在JSR 286中,有一个标准使Flex更容易阅读和更新用户首选项。
4)使用WSRP和其他远程portlet技术,门户服务器可以使用远程portlet并将所有请求代理回portlet提供程序。使用Flex时,这更加困难,因为门户服务器不知道如何代理Flex请求(HTTPService,RemoteObject,DataService等)。在许多情况下,唯一的解决方案是允许最终用户的机器直接与门户生产者服务器通信。但是很多时候这会导致IT问题,因为这意味着将另一台服务器移动到DMZ并可能绕过门户网站服务器,SSO服务器,安全设备等施加的安全限制。
答案 1 :(得分:0)
看看www.qooxdoo.org。这是一个完全用javascript编写大型应用程序的框架。它结合了出色的GUI控件和用于javascript的java编程范例以及最终应用程序的巧妙构建过程。