Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 5
«Если внимательно почитать , то видно, что настройки рекомендуется передавать на jsp в виде атрибутов, хотя на самой jsp можно точно так же обратиться к настройкам через renderRequest.getPreferences().getValue(PREF_SHOWPERSONS,"") Зачем это делать - непонятно»
Возможно, для того, чтобы не рассказывать всей системе про javax.portlet.*, а во view настройки получать через обычный jstl — ${showPersonsList}
Возможно, для того, чтобы не рассказывать всей системе про javax.portlet.*, а во view настройки получать через обычный jstl — ${showPersonsList}
Что вы подразумеваете под "не рассказывать всей системе про javax.portlet.*"? А чем jstl лучше старой доброй jsp? Запись короче? Я вообще против jstl, Java - это не Колдфьюжн.
Подразумеваю ровно то, что написал. Зачем jsp знать о том, что она работает в среде портлет-контейнера, если в этом нет особой необходимости? Её дело — обеспечивать представление. Подготовили данные, передали — и пусть себе рисует.
Во-первых, привязка к портлету уменьшит возможность повторного использования этой jsp. В одном из следующих постов Вы наверняка нарисуете jsp, которая будет показывать информацию о найденном сотруднике. Вернёмся к нашей предыдущей беседе и вспомним один из недостатков портлетной технологии — проблему ссылок. Если в проекте когда-нибудь понадобится показывать информацию о сотруднике по простой короткой ссылке (/employee?12345), то, имея jsp, которая не привязана к портлетному окружению, мы можем использовать её повторно, просто установив нужные атрибуты из сервлета.
Во-вторых, чем больше мест, в которых методы окружения вызываются непосредственно — тем больше сложностей возникает, когда надо изменить поведение системы или написать workaround для чужого бага (ситуация, конечно, редкая, но, увы, не невероятная).
Да, есть конкретные портлеты и, вероятно, целые проекты, в которых заботиться о подобных вещах нет смысла. Но говорить в обучающей статье (утрирую) "не понимаю, нафига такие сложности" — на мой взгляд, неправильно.
Что касается jstl, то код с ним выглядит аккуратнее, чем каша из скриптлетов. Ещё такой код проще генерировать в xsl по какому-нибудь DSL, но это уже очень специфический плюс :)
ps: в листинге <%@page import="javax.portlet.*"%> два раза написан.
Во-первых, привязка к портлету уменьшит возможность повторного использования этой jsp. В одном из следующих постов Вы наверняка нарисуете jsp, которая будет показывать информацию о найденном сотруднике. Вернёмся к нашей предыдущей беседе и вспомним один из недостатков портлетной технологии — проблему ссылок. Если в проекте когда-нибудь понадобится показывать информацию о сотруднике по простой короткой ссылке (/employee?12345), то, имея jsp, которая не привязана к портлетному окружению, мы можем использовать её повторно, просто установив нужные атрибуты из сервлета.
Во-вторых, чем больше мест, в которых методы окружения вызываются непосредственно — тем больше сложностей возникает, когда надо изменить поведение системы или написать workaround для чужого бага (ситуация, конечно, редкая, но, увы, не невероятная).
Да, есть конкретные портлеты и, вероятно, целые проекты, в которых заботиться о подобных вещах нет смысла. Но говорить в обучающей статье (утрирую) "не понимаю, нафига такие сложности" — на мой взгляд, неправильно.
Что касается jstl, то код с ним выглядит аккуратнее, чем каша из скриптлетов. Ещё такой код проще генерировать в xsl по какому-нибудь DSL, но это уже очень специфический плюс :)
ps: в листинге <%@page import="javax.portlet.*"%> два раза написан.
"Подразумеваю ровно то, что написал. Зачем jsp знать о том, что она работает в среде портлет-контейнера, если в этом нет особой необходимости? Её дело — обеспечивать представление. Подготовили данные, передали — и пусть себе рисует."Режим настройки специфичен для портлета, соответственно, вряд ли jsp-представление режима настройки будет "реюзаться". Я себе не представляю эту ситуацию.
Доступ к jsp, находящейся в портлетном приложении можно осуществлять по ссылке:
http://portal.ru/contextNameOfApp/jsp/someportlet_view.jsp
contextNameOfApp можно узнать после деплоя приложения на сервер (по крайней мере так все работает у IBM). Как все устроен у Sun, я пока что не знаю. Для более полного тестирования портала нужно хотя бы 8-10 портлетов наплодить, чем я и занимаюсь. Пока что используется драйвер портлетов.
Но говорить в обучающей статье (утрирую) "не понимаю, нафига такие сложности"
Я действительно не понимаю зачем в представление режима настройки передавать настройки, чтобы в режиме настройки их представить и поменять. Настройка есть для конкретного портлета, она нужна только ему и больше никому. по что ответ на свой вопрос я не нашел.
Насчет jstl аккуратней - согласен, но нужно учить кучу тегов и т.д и т.п. Ждавийный зоопарк технологий и так голову перегружает, если еще загружаться тегами jstl, которые используются только в одном месте, то голова лопнет. Нельзя же без конца что-то лучшать и добавлять. Меру надо знать.
JSTL должен учить дизайнер, которому нужно динамику в HTML-ины вставлять. Ато иначе в чистом JSP ему прийдётся собственно учить Java, что дизайнеру будет не в пример сложнее чем выучить несколько тегов.
Собственно говоря механизм таглибов для того и нужен — чтоб гуру Java таглиб написал, а остальные его юзали в виде тегов и в дебри Java-кода не лезли.
Собственно говоря механизм таглибов для того и нужен — чтоб гуру Java таглиб написал, а остальные его юзали в виде тегов и в дебри Java-кода не лезли.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создаем портлетное приложение по JSR286, часть первая