Comments 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-кода не лезли.
Sign up to leave a comment.
Создаем портлетное приложение по JSR286, часть первая