Ограничения/недостатки разработки портлетов для Liferay

Ответ 1

(Отказ от ответственности: я один из разработчиков Liferay)

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

Разработка портлета для Liferay начинает окупаться, когда вы начинаете использовать предоставляемые им услуги портала. Для начала, создав портлет, вы можете забыть о разработке собственной пользовательской системы и использовать тот, который предоставляет Liferay (что довольно эффективно). Вы также можете использовать другие службы, такие как разрешения, комментарии, тегирование, категоризацию, область данных и т.д., Которые позволят вам разработать довольно полное приложение за более короткое время. Недостатком является то, что в первый раз, когда вы это сделаете, вам придется изучать несколько новых вещей, но во второй раз вы будете намного быстрее.

Я надеюсь, что это поможет.

Ответ 2

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

Если вам нужны варианты макета для нескольких приложений, которые вы можете получить с портала, то вы обязательно должны использовать Liferay. Если вы пишете одно приложение, я бы, вероятно, не использовал Liferay. Я думаю, что гибрид некоторых Liferay и некоторые из них далеко не самый худший вариант.

Мы, вероятно, не используем Liferay для своих самых полных возможностей, но если это ваше первое приложение Liferay, то, скорее всего, вы не будете либо из-за кривой обучения. Первоначально мы надеялись иметь много разных портлетов для различных аспектов нашего приложения, но из-за отсутствия хороших механизмов взаимодействия между портлетами во время разработки (pre JSR-286) мы закончили писать одно приложение. Теперь, когда мы оказались в этой лодке, я бы хотел, чтобы мы ушли без Liferay, поскольку все, что мы действительно используем, - это некоторые возможности управления пользователями.

Мы используем JSF и facelets (как новые технологии для нас, так и боль, возможно, были подвергнуты саморазрушению), и пока мы стали лучше, кажется, что было несколько обручей, которые нам пришлось перепрыгнуть, чтобы заставить его работать правильно в портлете; Вещи, которые не должны были бы происходить в обычной среде веб-приложений. Для многих фреймворков кажется, что поддержка портлета является запоздалой мыслью. Это, очевидно, не конкретный Liferay, а просто побочный продукт работы в среде портлета.

В webapp с использованием Spring MVC, Struts, Faces, Wicket, независимо от того, у вас будет намного больше контроля над всем, но также будет ответственным за внедрение большего количества материалов.

В портлете вы будете подчиняться условиям JSR-168 и/или JSR-286. Контейнер портала предоставит вам некоторые функции, такие как аутентификация пользователей, но IMO, весь портал для аутентификации пользователей слишком тяжелый. Я вижу, что мощность портала позволяет пользователю настраивать свое представление о нескольких приложениях, не представляя одного приложения.

Вы должны просмотреть спецификации, связанные с портлетом, и посмотреть, соответствует ли он вашим потребностям.

http://developers.sun.com/portalserver/reference/techart/jsr168/

Ответ 3

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

Ответ 4

Liferay и портлеты в целом отлично подходят для очень специфического класса приложений. Если вы работаете в ИТ-отделе и вам нужно комбинировать приложения для нескольких отделов, то портлеты будут в пути. Теоретически вы можете бросить портлеты у разных вендоров, и все они будут жить в гармонии внутри одной и той же среды.

Однако, если вы создаете приложение, которое является любым из следующих

1), созданный полностью одной командой 2) имеет единственный источник требований 3) имеет требования, которые не являются подмножеством функций, доступных в контейнере портлетов. 4) имеет графический дизайнер, который не желает жить в рамках приложений стиля портала.

тогда придерживаться чего-то типа Spring было бы возможным.

Spring, и его множество подпроектов предоставляют множество общих служб и инфраструктуры, предлагаемых портлетами, но они предлагаются открытым и более гибким способом. Вы можете выбрать и выбрать то, что хотите.

Портлеты принимают множество дизайнерских решений для вас с точки зрения аутентификации и авторизации, навигации и макета. Если планы, которые у вас есть для вашего приложения, выходят за рамки этих решений, вы потратите много времени на создание обходных решений, чтобы попытаться сделать то, что вы хотите.

Ответ 5

Все, пожалуйста, не принимайте это как троллинг/пылающий. Это то, что я чувствую, когда сообщество Liferay должно обратиться, и все, кто думает об использовании Liferay, должны знать.

Недостаток: нет документации. Ничто даже отдаленно не похоже, например, документация Hibernate. Просто пустой javadock (без комментариев в коде), некоторые ответили на вопросы в форумах и книгах для старых версий (бесполезно).

Ответ 6

Я всегда думал, что Порталы, такие как Liferay, следует рассматривать как схожие с общей инфраструктурой. Они обеспечивают общий доступ к приложениям, общим службам (например, аутентификации) и стандартным способам развертывания, но за счет производительности.

Если вы намерены развернуть больше, чем просто это приложение в Portal, то да, вероятно, это уместно, так как вы получите экономию времени и затрат, не имея необходимости разрабатывать эти общие службы во второй раз. И последующие приложения будут выглядеть и вести себя аналогично этому.

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

Ответ 7

Liferay имеет функциональность CMS и может интегрироваться с внешними платформами CMS, такими как Alfresco.

Ответ 8

Man, проверьте это решение. Netbeans IDE + PoralPack3.0 plugin + Liferay 5.2 bundle. Пакет Portal здесь поможет вам, предоставив красивый графический редактор для файла service.xml, где вы можете определить сущности или структуры базы данных, и из того же графического интерфейса вы можете создать код сервисов, который можно использовать внутри вашего портлета.

Для получения дополнительной информации проверьте приведенную ниже ссылку: http://www.liferay.com/web/satyaranjan/blog/-/blogs/portal-pack-:-write-database-portlet-using-service-builder-plug-in