On 11/27/05, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > [moved from [EMAIL PROTECTED] > > On 11/25/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > > I'll see if I can find it and change the MailReader app, then. > > > > It'd mean extending either AbstractFacesBean or AbstractViewController > on > > the backing bean classes. > > I took the methods out of mailreader; BaseViewController already > extended AbstractViewController. > > > I haven't had a chance to review the Shale Mailreader example much yet > (and > > it's not included in the 1.0.0-rc1 candidate), so don't sweat it too > much > > ... unless you want to get immersed into JSF and become a convert of > course > > :-). > > You never know. :) First I had to invent a project to use it in, my > current assignment involves BASIC and SQL. > > For a long time I couldn't reconcile the advice to keep > ViewControllers in request scope. All of my Struts forms are session > scoped and I'm used to having the forms 'remember' their values.
That actually works for JSF backing beans in general, so you can indeed have persistent form data if you want. I'd still model the per-request events in a request-scoped ViewController though. Dropping the properties from the ViewController and just putting a > business object in session scope seems to be working. But that's more > or less a session scoped form bean, especially since my database is > untyped and the properties are mostly Strings. Where should I put > form data that needs to be there throughout the session? Session scope is certainly a good place to store stuff that needs to last longer than one request ... and nothing stops you from binding some fields in a page to such "persistent" properties, and other fields in the page to the more "transient" properties related to a particular request scoped ViewController. At least I have progressed beyond the 'nothing but stack traces' > stage, so things are improving. ;) Cool :-). -- > Wendy Craig
