You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Kris Verhoye <kr...@synergetic-solutions.be> on 2005/06/13 16:50:51 UTC
General faces questions: messages, lifecycle
Hi!
My application messages always appear twice in the messages list. I have
an x:messages tag in my pages with only an id and styleClass attribute,
but the same happens when using the h:messages tag. What could I do
wrong here? When I use h:message, the relative messages come out once.
BTW, is it so that one never can be sure if a setter is going to be
invoked, even if the value of the input hasn't been changed? What is the
most common way to track changes then? An onchange listener?
Thanks for any help!
Kris
Re: getter/setter, lifecycle
Posted by Slawek <ss...@o2.pl>.
hmm i have never considered it as a problem cause im using jscookmenu...
for example: when i want to see users i click on JSmenu action
users.showAll() that return string mapped to
users.jsp
but this method is not trivial;) before return, method does all business
logic so i dont need to perform any logic
in getters.
> I had the same problem as you. My backing bean would often need to hit
> my business tier and subsequently my database tier in order to
> retrieve valid values for drop down lists. Obviously this starts to
> become expensive if jsf is hitting the managed bean getter multiple
> times. What i found to work (maybe someone knows a simpler way) was
> using aspectj and writing an aspect which cached the value returned
> from a backing bean getter method for the duration of a single
> request. This way if the managed bean's getter was called multiple
> times it would only run through the entire method once. Once the
> request has finished the cache is cleared so that on next request you
> be sure to get the latest values. I also wrote advice for setter
> methods of the managebean to be sure to update the cached value if it
> was present.
>
> Good luck
>
> On 6/14/05, Kris Verhoye <kr...@mediamine.com> wrote:
>> Hi again!
>>
>> I've been reading through the lifecycle theory again and am confused
>> about
>> the way getters and setters are handled:
>>
>> How comes that a backing bean getter/setter may be called more than once
>> during the lifecycle, and how does one initialize a list of selectItems
>> stored in a session scoped bean that should be refreshed every request?
>>
>> If I perform the construction of the list in a getter, it would be
>> executed
>> more than once. I can't do it in the constructor however as the bean is
>> not
>> constructed every request...
>>
>> Cheers,
>> Kris
>>
>>
>>
>>
>
Re: getter/setter, lifecycle
Posted by Galen Dunkleberger <ga...@gmail.com>.
I had the same problem as you. My backing bean would often need to hit
my business tier and subsequently my database tier in order to
retrieve valid values for drop down lists. Obviously this starts to
become expensive if jsf is hitting the managed bean getter multiple
times. What i found to work (maybe someone knows a simpler way) was
using aspectj and writing an aspect which cached the value returned
from a backing bean getter method for the duration of a single
request. This way if the managed bean's getter was called multiple
times it would only run through the entire method once. Once the
request has finished the cache is cleared so that on next request you
be sure to get the latest values. I also wrote advice for setter
methods of the managebean to be sure to update the cached value if it
was present.
Good luck
On 6/14/05, Kris Verhoye <kr...@mediamine.com> wrote:
> Hi again!
>
> I've been reading through the lifecycle theory again and am confused about
> the way getters and setters are handled:
>
> How comes that a backing bean getter/setter may be called more than once
> during the lifecycle, and how does one initialize a list of selectItems
> stored in a session scoped bean that should be refreshed every request?
>
> If I perform the construction of the list in a getter, it would be executed
> more than once. I can't do it in the constructor however as the bean is not
> constructed every request...
>
> Cheers,
> Kris
>
>
>
>
Re: getter/setter, lifecycle
Posted by Craig McClanahan <cr...@gmail.com>.
On 6/14/05, albartell <al...@gmail.com> wrote:
> > Why are you hung up on using only one backing bean? Use as many as
> you need -- and needing different lifetimes for data is *definitely* a
> good reason to use more than one bean as necessary.
>
> I agree this is the direction I need to head. I was just concerned about
> the number of objects and how to organize (say name) them. I have used IBM's
> Websphere IDE and they create a backing bean per page which seems like the
> appropriate amount to create.
>
Sun Java Studio Creator (disclaimer: that's the product I am
architect for) goes a bit further -- we also create a session-scoped
managed bean and an application-scoped managed bean for you. Then we
make it easy to add property getters that can do caching-like things,
and then bind to them.
A request scoped backing bean per page is fine for stuff that only
needs to be visible through the current request, for the current page.
If you need stuff longer, keep it in a bean that is in a longer
scope.
>
> >... It is not JSF's responsibility to ensure that you make sure
> getStates() is as efficient as possible.
>
> Given your example I would fully expect the getter to be called twice if
> there are two components on the screen accessing the same backing bean
> property. But that isn't the scenario I have. I instead have a single field
> (i.e. title - Mr., Ms., Mrs. etc) that is only specified once on the page,
> but the getter will still be called more than once in some instances.
>
That all depends on how many expression evaluations occur, because JSF
never calls these methods by itself ... it only resolves expressions
for you.
> > If you like init() and destroy() on backing beans, you'll definitely
> like Shale :-)
>
> Looks like I need to break down and do a little reading :-)
>
Yep :-)
> Thanks for your response,
> Aaron Bartell
>
Craig
>
>
>
RE: getter/setter, lifecycle
Posted by albartell <al...@gmail.com>.
> Why are you hung up on using only one backing bean? Use as many as
you need -- and needing different lifetimes for data is *definitely* a
good reason to use more than one bean as necessary.
I agree this is the direction I need to head. I was just concerned about
the number of objects and how to organize (say name) them. I have used IBM's
Websphere IDE and they create a backing bean per page which seems like the
appropriate amount to create.
>... It is not JSF's responsibility to ensure that you make sure
getStates() is as efficient as possible.
Given your example I would fully expect the getter to be called twice if
there are two components on the screen accessing the same backing bean
property. But that isn't the scenario I have. I instead have a single field
(i.e. title - Mr., Ms., Mrs. etc) that is only specified once on the page,
but the getter will still be called more than once in some instances.
> If you like init() and destroy() on backing beans, you'll definitely
like Shale :-)
Looks like I need to break down and do a little reading :-)
Thanks for your response,
Aaron Bartell
Re: getter/setter, lifecycle
Posted by Craig McClanahan <cr...@gmail.com>.
On 6/14/05, albartell <al...@gmail.com> wrote:
> Craig, regarding your first statement about making the bean a request scope
> vs session...
>
> Maybe I put too much into one backing bean (one backing bean runs multiple
> related screens) but in my case I need some values (say properties) to
> remain at session scope and others to be at request scope.
Why are you hung up on using only one backing bean? Use as many as
you need -- and needing different lifetimes for data is *definitely* a
good reason to use more than one bean as necessary.
This makes
> Galen's approach with AspectJ appealing, but it would be even better if I
> could specify right on the property that the getter method should only be
> called once.
That's not the kind of restriction that well written applications
impose on their callers :-). I already showed how (earlier in this
thread) you can make the number of calls irrelevant.
Seriously, you're going to want to use a similar technique ... so you
might as well use it here too.
> I have read most of the JSF spec and at the time had a 1,000
> ft understanding of why the getters weren't guaranteed to be called only
> once, but I would still like to see something implemented into the spec that
> allows the bypassing of a secondary call rather than implementing an
> "if(property==null)" type approach.
>
Very simple ... besides being bad design, it would be impossible to enforce.
Consider a case where you have a method like this on an application
scope bean (with the managed bean name "appicationBean"), to return an
array of SelectItem[] for the abbreviations and names of the US
states:
public SelectItem[] getStates();
Now, consider that you're writing an order entry application that has
both a billing address and a shipping address on the same page. So,
you end up with code like this:
<h:selectOneDropDown id="billToState" ...>
<h:selectItems ... value="#{applicationBean.states}"/>
</h:selectOneDropDown>
...
<h:selectOneDropDown id="shipToState" ...>
<h:selectItems ... value="#{applicationBean.states}"/>
</h:selectOneDropDown>
So, getStates() is going to be called twice, right? Because the
*application* wants to, right?
It is not JSF's responsibility to ensure that you make sure
getStates() is as efficient as possible.
> I guess the question in my head is how would one elegantly code a property
> to execute its code only once in a bean that is session scoped? Because the
> below example will only work the first time the session bean is invoked, but
> the second visit to the page it will already be full (with old information).
I already posted an example of this earlier in this thread.
>
> It would be cool to have a destroy() or destructor method for each backing
> bean for clean up purposes. I have pseudo implemented this with a method in
> my code called "cleanupConstructor()", but I ran into problems with my ORM
> solution's values getting waxed before data was persisted to the database
> (design flaw on my end).
>
If you like init() and destroy() on backing beans, you'll definitely
like Shale :-)
http://struts.apache.org/shale/
> Aaron Bartell
> http://mowyourlawn.com
>
Craig
RE: getter/setter, lifecycle
Posted by albartell <al...@gmail.com>.
Craig, regarding your first statement about making the bean a request scope
vs session...
Maybe I put too much into one backing bean (one backing bean runs multiple
related screens) but in my case I need some values (say properties) to
remain at session scope and others to be at request scope. This makes
Galen's approach with AspectJ appealing, but it would be even better if I
could specify right on the property that the getter method should only be
called once. I have read most of the JSF spec and at the time had a 1,000
ft understanding of why the getters weren't guaranteed to be called only
once, but I would still like to see something implemented into the spec that
allows the bypassing of a secondary call rather than implementing an
"if(property==null)" type approach.
I guess the question in my head is how would one elegantly code a property
to execute its code only once in a bean that is session scoped? Because the
below example will only work the first time the session bean is invoked, but
the second visit to the page it will already be full (with old information).
It would be cool to have a destroy() or destructor method for each backing
bean for clean up purposes. I have pseudo implemented this with a method in
my code called "cleanupConstructor()", but I ran into problems with my ORM
solution's values getting waxed before data was persisted to the database
(design flaw on my end).
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: Craig McClanahan [mailto:craigmcc@gmail.com]
Sent: Tuesday, June 14, 2005 11:14 AM
To: MyFaces Discussion; kris.verhoye@mediamine.com
Subject: Re: getter/setter, lifecycle
If your list of select items really should be constructed for every
reequest, there's no reason to put it in a session scoped bean -- but
it in a request scoped bean instead (either a common one for shared
items lists, or a page-specific one if it's unique.
To avoid constructing the list multiple times, even if the getter is
called more than once (it will get called once per value binding
expression that points at it), use a common Java idiom in the request
scoped backing bean:
private SelectItem items[] = null;
public SelectItem[] getItems() {
if (items == null) {
items = ...; // Fill up the list
}
return items;
}
Craig
On 6/14/05, Kris Verhoye <kr...@mediamine.com> wrote:
> Hi again!
>
> I've been reading through the lifecycle theory again and am confused about
> the way getters and setters are handled:
>
> How comes that a backing bean getter/setter may be called more than once
> during the lifecycle, and how does one initialize a list of selectItems
> stored in a session scoped bean that should be refreshed every request?
>
> If I perform the construction of the list in a getter, it would be
executed
> more than once. I can't do it in the constructor however as the bean is
not
> constructed every request...
>
> Cheers,
> Kris
>
>
>
>
Re: getter/setter, lifecycle
Posted by Craig McClanahan <cr...@gmail.com>.
If your list of select items really should be constructed for every
reequest, there's no reason to put it in a session scoped bean -- but
it in a request scoped bean instead (either a common one for shared
items lists, or a page-specific one if it's unique.
To avoid constructing the list multiple times, even if the getter is
called more than once (it will get called once per value binding
expression that points at it), use a common Java idiom in the request
scoped backing bean:
private SelectItem items[] = null;
public SelectItem[] getItems() {
if (items == null) {
items = ...; // Fill up the list
}
return items;
}
Craig
On 6/14/05, Kris Verhoye <kr...@mediamine.com> wrote:
> Hi again!
>
> I've been reading through the lifecycle theory again and am confused about
> the way getters and setters are handled:
>
> How comes that a backing bean getter/setter may be called more than once
> during the lifecycle, and how does one initialize a list of selectItems
> stored in a session scoped bean that should be refreshed every request?
>
> If I perform the construction of the list in a getter, it would be executed
> more than once. I can't do it in the constructor however as the bean is not
> constructed every request...
>
> Cheers,
> Kris
>
>
>
>
getter/setter, lifecycle
Posted by Kris Verhoye <kr...@mediamine.com>.
Hi again!
I've been reading through the lifecycle theory again and am confused about
the way getters and setters are handled:
How comes that a backing bean getter/setter may be called more than once
during the lifecycle, and how does one initialize a list of selectItems
stored in a session scoped bean that should be refreshed every request?
If I perform the construction of the list in a getter, it would be executed
more than once. I can't do it in the constructor however as the bean is not
constructed every request...
Cheers,
Kris
RE: General faces questions: messages, lifecycle
Posted by Kris Verhoye <kr...@synergetic-solutions.be>.
Okido, thanks! I'll use the change listeners then...
Regarding the messages tag: I'll try that again (though I think I tried
it in the beginning), but I only have one message in my resource bundle
(I don't use '_detail'): would the tag display messages twice even
without such a detail entry in the bundle?
Thanks again!!
Kris
-----Original Message-----
From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
Sent: 13 June 2005 16:56
To: MyFaces Discussion; kris.verhoye@synergetic-solutions.be
Subject: Re: General faces questions: messages, lifecycle
Second question: yes, a valueChange Listener is the most common way to
track changes i inputs.
As for the first question: have you tried playing around with
showDetail and showSummary as in:
<x:messages errorClass="errorMessage" infoClass="infoMessage"
showSummary="false" showDetail="true"/>
regards,
Martin
On 6/13/05, Kris Verhoye <kr...@synergetic-solutions.be> wrote:
> Hi!
>
> My application messages always appear twice in the messages list. I
> have an x:messages tag in my pages with only an id and styleClass
> attribute, but the same happens when using the h:messages tag. What
> could I do wrong here? When I use h:message, the relative messages
> come out once.
>
> BTW, is it so that one never can be sure if a setter is going to be
> invoked, even if the value of the input hasn't been changed? What is
> the most common way to track changes then? An onchange listener?
>
> Thanks for any help!
> Kris
>
>
Re: General faces questions: messages, lifecycle
Posted by Martin Marinschek <ma...@gmail.com>.
Second question: yes, a valueChange Listener is the most common way to
track changes i inputs.
As for the first question: have you tried playing around with
showDetail and showSummary as in:
<x:messages errorClass="errorMessage" infoClass="infoMessage"
showSummary="false" showDetail="true"/>
regards,
Martin
On 6/13/05, Kris Verhoye <kr...@synergetic-solutions.be> wrote:
> Hi!
>
> My application messages always appear twice in the messages list. I have
> an x:messages tag in my pages with only an id and styleClass attribute,
> but the same happens when using the h:messages tag. What could I do
> wrong here? When I use h:message, the relative messages come out once.
>
> BTW, is it so that one never can be sure if a setter is going to be
> invoked, even if the value of the input hasn't been changed? What is the
> most common way to track changes then? An onchange listener?
>
> Thanks for any help!
> Kris
>
>