On 6/14/05, albartell <[EMAIL PROTECTED]> 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
