Liferay для доставки RIA

Question

В настоящее время я ищу Flex и Liferay для предоставления RIA. Мы заменяем довольно большое существующее приложение, построенное на внутренней библиотеке AJAX / Java. Для этого, кажется, Flex отвечает нашим потребностям в разработке, но мы получили ключ к работе. Нам нужно интегрироваться с другим внутренним приложением, которое построено на Liferay и JSF.

Немного заглянув в Liferay, я не уверен, что это дает какие-либо преимущества нашему существующему приложению, поскольку доставка через портлет, по-видимому, не имеет каких-либо внутренних преимуществ, кроме достижения интеграции с другим приложением. Он также имеет ряд недостатков, в том числе плавное взаимодействие между SWF и остальной частью страницы, подключение к управлению пользователями Liferay и их общее отсутствие документации, ориентированной на разработчика.

Мне кажется, Liferay - хорошее решение, если вам нужно внутреннее приложение для вики / новостей / социальных сетей, но для доставки надежной RIA кажется, что мы пытаемся вставить квадратный колышек в круглое отверстие.

У меня такой вопрос: используется ли Liferay для доставки полных приложений RIA или это платформа, которая лучше подходит для доставки небольших приложений? Я что-то упускаю из Liferay, что делает его подходящим для RIA?

Заранее спасибо за любой совет!

Answer 1

Взгляните на www.qooxdoo.org . Это основа для написания больших приложений полностью на javascript. Он сочетает в себе превосходное управление графическим интерфейсом с Java-подобной парадигмой программирования для javascript и умный процесс сборки для конечного приложения.

Answer 2

Вы можете легко заставить приложение Flex отображаться на портале (Liferay или другом), но вот некоторые проблемы, с которыми вы можете столкнуться:

1) Типичные серверы портала хранят все состояние - для всехпортлетов - на сервере.Каждое взаимодействие вызывает обновление страницы, которое перерисовывает все на странице в зависимости от состояния сервера.Для приложений Flex обычно не требуется состояние на сервере.И вам не нужно, чтобы каждое взаимодействие перезагружало приложение Flex.Некоторые порталы получают больше Ajax'y, который решает часть этого, но всегда будут некоторые взаимодействия в портлетах HTML или в хроме портала, которые вызывают обновление страницы.Это означает, что приложения Flex должны выполнить некоторую работу, чтобы сохранить состояние после обновления страницы.Простой способ сделать это - использовать LSO, но для этого требуется много дополнительного кода.

2) Межпортлетное взаимодействие (в порталах JSR 168) проходит через сервер на основе обновления страницы.Это также не очень хорошо работает с приложениями Flex.JSR 286 пытается решить эту проблему для поддержки Ajax-портлета IPC.До тех пор заставить приложения Flex работать со стандартным IPC было сложно (но возможно).

3) Большая часть порталов - это права, настройки и предпочтения.Все это сложно использовать и взаимодействовать с Flex.В порталах JSR 168 нет стандартного способа сделать это.В JSR 286 существует стандарт, упрощающий для Flex чтение и обновление пользовательских настроек.

4) При использовании WSRP и других технологий удаленных портлетов серверы портала могут использовать удаленные портлеты и передавать все запросы обратно поставщику портлетов.,С Flex это сложнее, потому что серверы портала не знают, как прокси-запросы Flex (HTTPService, RemoteObject, DataService и т. Д.).Во многих случаях единственное решение - позволить компьютеру конечного пользователя напрямую общаться с сервером производителя портала.Однако часто это создает проблемы для ИТ-специалистов, поскольку означает перемещение другого сервера в DMZ и, возможно, обход ограничений безопасности, налагаемых сервером портала, сервером единого входа, устройством безопасности и т. Д.