Liferay 用于提供 RIA
我目前正在研究 Flex 和 Liferay 来提供 RIA。我们正在替换一个基于内部 AJAX/Java 库构建的相当大的现有应用程序。为此，Flex 似乎满足了我们的开发需求，但我们在工作中遇到了困难。我们需要与另一个基于 Liferay 和 JSF 构建的内部应用程序集成。
在研究了一点 Liferay 之后，我不相信它能为我们现有的应用程序提供任何好处，因为除了实现与其他应用程序的集成之外，通过 portlet 进行交付似乎没有任何固有的好处。它似乎也有许多缺点，包括 swf 和页面其余部分之间的平滑交互、与 Liferay 的用户管理挂钩以及普遍缺乏面向开发人员的文档。
在我看来，如果您需要内部 wiki/新闻/社交应用程序，Liferay 是一个很好的解决方案，但为了提供强大的 RIA，我们似乎正在尝试在圆孔中安装一个方钉。
我的问题是：Liferay 是用于交付完整的 RIA 应用程序还是一个更适合交付较小应用程序的平台？我是否遗漏了 Liferay 中某些使其非常适合 RIA 的内容？
预先感谢您的任何建议！
I am currently looking into Flex and Liferay for delivering an RIA. We are replacing a rather large existing application built on an internal AJAX/Java library. For this, Flex seems to meet our needs for development but we've had a wrench thrown into the works. We need to integrate with another internal app that's been built on Liferay and JSF.
After looking into Liferay a bit I'm not convinced that it provides any benefits to our existing application since delivery via a portlet doesn't appear to have any inherent benefits other than achieving the integration with the other application. It also appears to have a number of downsides including smooth interaction between the swf and the rest of the page, hooking into Liferay's user management and their general lack of developer oriented documentation.
It seems to me Liferay is a good solution if you need an internal wiki/news/social application, but for delivery of a robust RIA it seems like we're trying to fit a square peg in a round hole.
My question is this: Is Liferay used for delivering full RIA applications or is it a platform that's better suited to delivering smaller apps? Am I missing something about Liferay that makes it a good fit for RIA?
Thanks in advance for any advice!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以轻松地让 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 服务器、安全设备等施加的安全限制。
You can easily get a Flex app to show up in a portal (Liferay or other) but here are some issues you might run into:
1) Typical portal servers hold all of the state - for all of the portlets - on the server. Every interaction causes a page refresh which rerenders everything on the page based on the serverside state. For Flex applications you don’t usually want the state on the server. And you don’t want every interaction reloading the Flex app. Some portals are getting more Ajax’y which solves part of this but there will always be some interactions in HTML portlets or in the portal chrome that cause a page refresh. This means that Flex applications must done some work to persist state beyond a page refresh. A simple way to do this is using LSOs but this requires a lot of extra plumbing code.
2) Inter-Portlet-Communication (in JSR 168 portals) goes through the server based on a page refresh. This also doesn’t work well with Flex apps. JSR 286 is attempting to solve this to support Ajax portlet IPC. Until then making Flex apps work with standard IPC is difficult (but possible).
3) A big part of portals is entitlements, customizations, and preferences. These are all difficult to use and interact with from Flex. In JSR 168 portals there isn’t a standard way of doing this. In JSR 286 there is a standard which makes it easier for Flex to read and update user preferences.
4) With WSRP and other remote portlet technologies portal servers can consume remote portlets and proxy all requests back to the portlet provider. With Flex this is more difficult because portal servers don’t know how to proxy Flex requests (HTTPService, RemoteObject, DataService, etc). In many cases the only solution is to allow the end user’s machine to talk directly to the portal producer server. However many times this causes problems for IT because it means moving another server to the DMZ and potentially bypassing the security constraints imposed by the portal server, SSO server, Security Appliance, etc.
请访问 www.qooxdoo.org。这是一个完全用 JavaScript 编写大型应用程序的框架。它将出色的 GUI 控制与类似 java 的 javascript 编程范例以及最终应用程序的巧妙构建过程结合在一起。
Have a look at www.qooxdoo.org. This is a framework for writing large applications entirely in javascript. It combines excellent GUI control with a java like programming paradigm for javascript and a clever build process for the final application.