Ограничения / недостатки разработки портлетов для Liferay
Я подумываю о разработке приложения в виде портлетов для интеграции в портал Liferay. Существуют ли какие-либо существенные недостатки или ограничения при разработке такого приложения по сравнению с разработкой обычного веб-приложения с использованием Spring Framework?
Кажется, Liferay требует, чтобы весь контент был добавлен в виде портлетов. Еще один вариант, который я обдумываю, - это использовать Liferay только для некоторых частей приложения и добавлять внешние ссылки на другой саморазвитый контент, разработанный как обычное веб-приложение. Это, однако, создало бы необходимость использования нескольких механизмов аутентификации пользователя и какой-либо межсайтовой аутентификации между Liferay и другим веб-приложением.
Какой лучший путь?
8 ответов
(Отказ от ответственности: я один из разработчиков Liferay)
Я думаю, что оба варианта хороши в зависимости от ваших потребностей. Если у вас есть опыт разработки автономных веб-приложений, но нет опыта в разработке портлетов, то выбор первого поможет вам быстрее начать работу. Недостатки заключаются в том, что вам придется внедрить собственную систему пользователей и разрешений, и вы не сможете использовать службы портала, предоставляемые Liferay. Если вы решите использовать эту альтернативу, обратите внимание, что вы можете развертывать обычные WAR-файлы в Liferay, и он автоматически создаст простой портлет, который использует iframe для отображения вашего приложения. Это позволит вам разместить автономное приложение вместе с портлетами на страницах Liferay.
Разработка портлета для Liferay начинает окупаться, когда вы начинаете использовать предоставляемые им службы портала. Чтобы начать с разработки портлета, вы можете забыть о разработке своей собственной пользовательской системы и использовать ту, которую предоставляет Liferay (которая является довольно мощной). Вы также можете использовать другие сервисы, такие как разрешения, комментарии, теги, категоризация, определение объема данных и т. Д., Которые позволят вам разработать довольно полное приложение за более короткое время. Недостатком является то, что в первый раз, когда вы это сделаете, вам придется изучить несколько новых вещей, но во второй раз вы пойдете намного быстрее.
Надеюсь, это поможет.
Я уже 2 года использую Liferay для внутреннего применения. У нас было одно и то же обсуждение много раз на протяжении всего цикла разработки до нашего первого выпуска. Нам пришлось сражаться с Liferay несколько раз, иногда из-за отсутствия собственных знаний, иногда из-за среды портлетов, а иногда из-за Liferay.
Если вам нужны параметры макета для нескольких приложений, которые вы можете получить с портала, то вам обязательно следует использовать Liferay. Если вы пишете одно приложение, я бы, вероятно, не использовал Liferay. Я думаю, что гибрид некоторых Liferay и некоторых не является худшим вариантом.
Вероятно, мы не используем Liferay в полной мере, но если это ваше первое приложение Liferay, скорее всего, вы тоже этого не сделаете из-за кривой обучения. Изначально мы надеялись иметь много разных портлетов для разных аспектов нашего приложения, но из-за отсутствия хороших механизмов взаимодействия между портлетами во время разработки (до JSR-286) мы в итоге написали одно приложение. Теперь, когда мы оказались в этой лодке, я хотел бы обойтись без Liferay, поскольку все, что мы действительно используем, это некоторые возможности управления пользователями.
Мы используем JSF и facelets (обе новые технологии для нас, так что боль, возможно, была связана с самим собой), и хотя мы стали лучше, кажется, что нам пришлось прыгнуть через несколько обручей, чтобы заставить его работать правильно в портлете; Вещи, которые не должны были бы происходить в обычной среде веб-приложений. Для многих фреймворков кажется, что поддержка портлетов является запоздалой мыслью. Это, очевидно, не специфично для Liferay, это просто побочный продукт работы в среде портлета.
В веб-приложении, использующем Spring MVC, Struts, Faces, Wicket, что угодно, вы будете иметь намного больший контроль над всем, но также будете ответственны за реализацию большего количества вещей.
В портлете вы будете подчиняться условиям JSR-168 и / или JSR-286. Контейнер портала предоставит вам некоторую функциональность, такую как аутентификация пользователя, но IMO, весь портал для аутентификации пользователя слишком тяжел. Я вижу мощь портала, позволяющего пользователю настраивать свой вид нескольких приложений, а не представлять одно приложение.
Вы должны ознакомиться со спецификациями портлета и посмотреть, соответствует ли он вашим потребностям.
http://developers.sun.com/portalserver/reference/techart/jsr168/
Liferay - чрезвычайно мощная система, существует множество готовых сервисов и приложений, но самым большим недостатком является отсутствие документации. Невозможно узнать все, просто глядя на код, так что, по моему мнению, если у вас нет опыта, не переходите на Liferay.
Liferay и портлеты в целом отлично подходят для очень специфического класса приложений. Если вы работаете в ИТ-отделе и вам нужно объединить приложения для нескольких отделов или из них, тогда портлетами будет путь. Теоретически вы можете добавить портлеты из разных поставщиков, и все они будут жить в гармонии в одной среде.
Однако, если вы создаете приложение, которое является одним из следующих
1) создан полностью одной командой 2) имеет единый источник требований 3) имеет требования, которые не являются подмножеством функций, доступных в контейнере портлета. 4) имеет графический дизайнер, который не хочет жить в рамках приложений в стиле портала.
тогда придерживаться чего-то вроде Spring было бы способом.
Spring и его многочисленные подпроекты предоставляют множество общих служб и инфраструктуры, предлагаемых портлетами, но они предлагаются открытым и более гибким способом. Вы можете выбрать то, что вы хотите.
Портлеты принимают множество дизайнерских решений для вас с точки зрения аутентификации и авторизации, навигации и макета. Если планы вашего приложения выходят за рамки этих решений, вы потратите много времени на создание обходных путей, чтобы попытаться заставить его делать то, что вы хотите.
Все, пожалуйста, не принимайте это как троллинг / пламя. Это то, что я считаю сообществом Liferay, и каждый, кто думает об использовании Liferay, должен знать.
Недостаток: нет документации. Ничего, даже удаленно, например, документация Hibernate. Просто пустой javadock (без комментариев в коде), некоторые ответы на вопросы в форумах и книгах по старым версиям (бесполезно).
Я всегда думал, что такие порталы, как Liferay, должны рассматриваться как общие для инфраструктуры. Они предоставляют общий способ доступа к приложениям, общим службам (например, аутентификация) и стандартный способ развертывания, но за счет производительности.
Если вы намереваетесь развернуть на Портале не только это приложение, то да, это, вероятно, целесообразно, поскольку вы получите экономию времени и средств от необходимости повторной разработки этих общих служб. И последующие приложения будут выглядеть и вести себя аналогично этому.
Однако, если это единственное приложение, которое нужно развернуть, тогда издержки портала не стоят того, и вам лучше использовать обычное веб-приложение.
Liferay имеет функциональность CMS и может интегрироваться с внешними платформами CMS, такими как Alfresco.
Человек, посмотрите это решение Netbeans IDE + плагин PoralPack3.0 + комплект Liferay 5.2. Пакет Portal Pack здесь помогает вам, предоставляя хороший редактор графического интерфейса для файла service.xml, где вы можете определять сущности или структуры базы данных, и из того же графического интерфейса вы можете генерировать код служб, который можно использовать внутри вашего портлета.
Для получения дополнительной информации проверьте приведенную ниже ссылку: http://www.liferay.com/web/satyaranjan/blog/-/blogs/portal-pack-:-write-database-portlet-using-service-builder-plug-in