Плюсы и минусы Java-портлетов? - PullRequest
6 голосов
/ 18 июля 2009

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

Ответы [ 3 ]

9 голосов
/ 11 августа 2012

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

Вот проблема:

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

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

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

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

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

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

5 голосов
/ 18 июля 2009

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

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

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

  • Javascript Framework - части на стороне сервера могут быть написаны на любом языке и размещены на любом сервере.
  • проще в использовании
  • многие серверы портала поддерживают его, и он более переносим между поставщиками, потому что он не так сложен и не требует от поставщиков реализации (и расширения)
3 голосов
/ 18 июля 2009

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

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

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

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

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

...