Плюсы и минусы портлетов Java?

У меня есть проект, в котором мой клиент просит меня использовать спецификации портлетов 1.0 и Websphere Portal Server 6.0. Раньше я не работал с портлетами, но то, что я слышал о них, всегда было плохой критикой. Каковы причины помимо очевидного их использования? Если не причины, то какие аргументы я мог бы использовать, чтобы избежать их?

6
evaluation java portlet

3 ответов

проблемы с портлетами напоминают мне о тех же проблемах, что и EJBs -

  • портлеты требуют, чтобы вы написали специальный код, который может быть размещен и запущен только на специальном сервере;
  • каждый поставщик сервера портлетов имеет пользовательские расширения / конфигурации / дополнительные возможности, поэтому нетривиально менять поставщиков серверов;
  • портлеты кажутся слишком сложными, чтобы охватить функциональность, которую 90% людей, желающих использовать его, не нужно

Я бы предложил что-то вроде Гаджеты Google как спящий режим для портлета EJB -

  • JavaScript framework-серверные части могут быть написаны на любом языке, размещенном на любом сервере.
  • проще использовать
  • многие серверы портала поддерживают его, и он более переносим между поставщиками, потому что он не такой сложный, и это не спецификация для поставщиков для реализации (и расширения)
5

Как кто-то, у кого было несколько заданий (включая мой текущий), разрабатывающих портлеты Java, я бы сказал, Не используйте их.

вот в чем проблема:

Если вы просто хотите использовать ранее существовавшие функции портала, который вы выбираете, используйте портал.

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

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

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

  • создание URL-адресов на другие страницы. Для этого вам понадобится конкретный для поставщика способ, поскольку API портлета позволяет создавать URL-адреса только для портлета, который их создал.
  • чтение и установка HTTP-заголовков или установка кода ответа HTTP (так что никаких перенаправлений или кэширования HTTP, так как вы не владеете страницей, на которой будет размещен портлет)
  • наличие пространства имен all идентификаторы на сгенерированной странице. Это означает атрибуты HTML id и имена функций JavaScript. Поскольку пространство имен должно быть определено во время выполнения для обеспечения уникальности, вы не можете иметь эти функции Javascript в отдельном файле, доступном для браузера, они должны быть в теле ответа для вашего портлета.

портлеты чувствуют, что они были разработаны для состояния веб-разработки, как это было в середине-конце 90-х годов (до AJAX). Но они плохо подходят для сегодняшней паутины среды разработки (AJAX, одностраничные веб-приложения и т. д.), которые предполагают, что у вас есть полный контроль над циклом запроса/ответа.

9

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

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

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

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

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

3