Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Java EE (J2EE) и Spring > JSF вызывает getter/setter несколько раз


Автор: introtel 11.10.2009, 00:44
Доброго времени суток!

В JSF getterы и setterы bean-ов вызываются несколько раз за время загружения страницы. Кто нибудь может обьяснить зачем и почему?
из Гугла узнал что "вызывается несколько раз за время рендеринга, валидации и еще чего-то там", но в чем причина реализации такого обращения?

Заранее спасибо!

Автор: ivg 11.10.2009, 09:26
В цикле обработки запроса состояние бина (читай значения полей объекта) может изменяться в следствие работы какого-то кода бина. Актуальные значения можно получить только вызвав соотв. геттер.

Автор: powerOn 11.10.2009, 23:33
Цитата(introtel @  11.10.2009,  01:44 Найти цитируемый пост)
В JSF getterы и setterы bean-ов вызываются несколько раз за время загружения страницы. Кто нибудь может обьяснить зачем и почему?
из Гугла узнал что "вызывается несколько раз за время рендеринга, валидации и еще чего-то там", но в чем причина реализации такого обращения?


Как тебе уже сказал гугл, обработка запроса в JSF имеет в какой-то степени сложную логику, состоящую из нескольких фаз. На каждой из них JSF нужно выполнять определенные действия: конвертировать/валидировать значения запроса, строить/восстанавливать/рендерить view, выполнять action-ы и т.д. Ну и, соответственно, для этого необходимо получать/устанавливать данные бина.
А, собственно, почему этот вопрос так беспокоит? Желаете гет/сет вызовы использовать как часть бизнес логики?

Автор: Bandit 12.10.2009, 01:50
powerOn, если честно, то я чаще всего именно их и использую в качестве обработчиков бизнес логики... Верно ли такое использование get, set - ов? 
Есть ли какие-то правила обработки в бинах или условные рекомендации? 

Автор: powerOn 12.10.2009, 08:08
Цитата(Bandit @  12.10.2009,  02:50 Найти цитируемый пост)
powerOn, если честно, то я чаще всего именно их и использую в качестве обработчиков бизнес логики... Верно ли такое использование get, set - ов? 
Есть ли какие-то правила обработки в бинах или условные рекомендации?  


Для обработки бизнес логики существуют init и action-методы, а так же listener-ы. Порядок вызовов гет/сет методов нигде не обусловлен, каждая реализация JSF может их дергать когда угодно и в каком угодно количестве, что естественно может повлиять на логику вашей программы.  

Автор: Bandit 12.10.2009, 12:33
powerOn,  можно ли глянуть пример твоего кода... Особенно что касается init методов и листнеров.
 smile 

Автор: introtel 12.10.2009, 20:19
Спасибо большое за ответ.
powerOn, а на производительность это никак не влияет? нельзя было с самой реализации организовывать кеширование, а то как видно все равно люди проверяют на "налл"-ость и только потом возрващают (так называемое lazy loading?)
был один баг связанный с тем что в JS динамически добвалялся параметр...несколько разsmile 
конечно бизнес логику туда пихать не надо...но проблема была в том, что организованно что-то типа трекинг системы, и должно это все работать например именно когда вызывается определенный геттер. простая проверка кончено спасает...но все-такки smile

Автор: powerOn 12.10.2009, 23:04
Цитата(Bandit @  12.10.2009,  13:33 Найти цитируемый пост)
powerOn,  можно ли глянуть пример твоего кода... Особенно что касается init методов и листнеров.


Немного не понял, что именно интересует. Init - методы реализуются либо через spring, либо аннотацией @PostConstruct. Смотри документацию. ActionListeners это вообще азы JSF, типа того: 

Код

<h:commandButton value="MyButton" action="#{SomeBean.someAction}" />



Цитата(introtel @  12.10.2009,  21:19 Найти цитируемый пост)
powerOn, а на производительность это никак не влияет? нельзя было с самой реализации организовывать кеширование, а то как видно все равно люди проверяют на "налл"-ость и только потом возрващают (так называемое lazy loading?)


мне трудно сказать насколько сильно это влияет на производительность, не не занимался подобного рода анализом. 

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)