You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Wendy Smoak <ws...@gmail.com> on 2005/11/26 02:18:18 UTC
[shale] mailreader question
This is probably a JSF question, but I'm already here. :)
MailReader's BaseViewController has:
protected Object getBean(String name) {
FacesContext context = getFacesContext();
return context.getApplication().getVariableResolver().
resolveVariable(context, name);
}
protected FacesContext getFacesContext() {
return FacesContext.getCurrentInstance();
}
Unwinding everything, I get:
FacesContext.getCurrentInstance().getApplication()
.getVariableResolver()
.resolveVariable(FacesContext.getCurrentInstance(), name);
All that, just to find my session scoped managed bean? Or am I making
it way more complicated than it needs to be? I *really* miss
'session.getAttribute()' right about now...
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [shale] mailreader question
Posted by Craig McClanahan <cr...@apache.org>.
On 11/27/05, Wendy Smoak <ws...@gmail.com> wrote:
>
> [moved from user@]
>
> On 11/25/05, Craig McClanahan <cr...@apache.org> 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
Re: [shale] mailreader question
Posted by Wendy Smoak <ws...@gmail.com>.
[moved from user@]
On 11/25/05, Craig McClanahan <cr...@apache.org> 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.
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?
At least I have progressed beyond the 'nothing but stack traces'
stage, so things are improving. ;)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] mailreader question
Posted by Craig McClanahan <cr...@apache.org>.
On 12/4/05, Wendy Smoak <ws...@gmail.com> wrote:
>
> On 11/25/05, Craig McClanahan <cr...@apache.org> wrote:
> > On 11/25/05, Wendy Smoak <ws...@gmail.com> wrote:
> > >
> > > On 11/25/05, Craig McClanahan <cr...@apache.org> wrote:
> > >
> > > > How do *you* know that it's a session scoped bean
> > > > (versus perhaps being in some other scope)?
> > >
> > > Because I put it there. The question first came up when I put my
> > > usual authentication Filter (which puts a 'user' bean in session
> > > scope) in front of a webapp, and then wandered around the JSF API for
> > > a while trying to figure out how on earth to get it back.
> >
> >
> > True in this specific case -- but that's an arbitrary restriction in the
> > general case. Sort of the same argument as for using dependency
> injection
> > frameworks in the first place ... lazy instantiation may not be what you
> > want for a "logged in user" bean, but it is generally quite useful.
>
> I'm still not sure about this one. That Filter has to be there, and I
> have to be able to find that 'user' bean later. If 'getBean' is the
> recommended way to retrieve beans in a ViewController... what happens
> if I go ahead and declare the 'user' as a session scoped managed bean,
> knowing that the Filter will put it in session scope?
>
> As far as I can tell, the framework should "notice" that the user bean
> is already there, and not try to create one. (If the app is ever in a
> state where the user bean is *not* in session scope, things have gone
> horribly wrong.)
That's exactly what happens. The managed bean facility *first* checks
whether there is a bean in any scope (request, session, then application)
with the given name. Only if there is no such bean will a new instance be
created (and put into whatever scope you have declared).
Shale doesn't need to do anything about this ... it's standard JSF behavior.
Or would you do this some other way?
>
> Thanks,
> --
> Wendy
Craig
---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: [shale] mailreader question
Posted by Wendy Smoak <ws...@gmail.com>.
On 11/25/05, Craig McClanahan <cr...@apache.org> wrote:
> On 11/25/05, Wendy Smoak <ws...@gmail.com> wrote:
> >
> > On 11/25/05, Craig McClanahan <cr...@apache.org> wrote:
> >
> > > How do *you* know that it's a session scoped bean
> > > (versus perhaps being in some other scope)?
> >
> > Because I put it there. The question first came up when I put my
> > usual authentication Filter (which puts a 'user' bean in session
> > scope) in front of a webapp, and then wandered around the JSF API for
> > a while trying to figure out how on earth to get it back.
>
>
> True in this specific case -- but that's an arbitrary restriction in the
> general case. Sort of the same argument as for using dependency injection
> frameworks in the first place ... lazy instantiation may not be what you
> want for a "logged in user" bean, but it is generally quite useful.
I'm still not sure about this one. That Filter has to be there, and I
have to be able to find that 'user' bean later. If 'getBean' is the
recommended way to retrieve beans in a ViewController... what happens
if I go ahead and declare the 'user' as a session scoped managed bean,
knowing that the Filter will put it in session scope?
As far as I can tell, the framework should "notice" that the user bean
is already there, and not try to create one. (If the app is ever in a
state where the user bean is *not* in session scope, things have gone
horribly wrong.)
Or would you do this some other way?
Thanks,
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [shale] mailreader question
Posted by Craig McClanahan <cr...@apache.org>.
On 11/25/05, Wendy Smoak <ws...@gmail.com> wrote:
>
> On 11/25/05, Craig McClanahan <cr...@apache.org> wrote:
>
> > How do *you* know that it's a session scoped bean (versus perhaps being
> in
> > some other scope)?
>
> Because I put it there. The question first came up when I put my
> usual authentication Filter (which puts a 'user' bean in session
> scope) in front of a webapp, and then wandered around the JSF API for
> a while trying to figure out how on earth to get it back.
True in this specific case -- but that's an arbitrary restriction in the
general case. Sort of the same argument as for using dependency injection
frameworks in the first place ... lazy instantiation may not be what you
want for a "logged in user" bean, but it is generally quite useful.
> Shale has an analogous method in its base class
> > that should really be used here :-).
>
> 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 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
:-).
Thanks!
> --
> Wendy
Craig
Re: [shale] mailreader question
Posted by Wendy Smoak <ws...@gmail.com>.
On 11/25/05, Craig McClanahan <cr...@apache.org> wrote:
> How do *you* know that it's a session scoped bean (versus perhaps being in
> some other scope)?
Because I put it there. The question first came up when I put my
usual authentication Filter (which puts a 'user' bean in session
scope) in front of a webapp, and then wandered around the JSF API for
a while trying to figure out how on earth to get it back.
> Shale has an analogous method in its base class
> that should really be used here :-).
I'll see if I can find it and change the MailReader app, then.
Thanks!
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [shale] mailreader question
Posted by Craig McClanahan <cr...@apache.org>.
On 11/25/05, Wendy Smoak <ws...@gmail.com> wrote:
>
> This is probably a JSF question, but I'm already here. :)
>
> MailReader's BaseViewController has:
>
> protected Object getBean(String name) {
> FacesContext context = getFacesContext();
> return context.getApplication().getVariableResolver().
> resolveVariable(context, name);
> }
>
> protected FacesContext getFacesContext() {
> return FacesContext.getCurrentInstance();
> }
>
> Unwinding everything, I get:
>
> FacesContext.getCurrentInstance().getApplication()
> .getVariableResolver()
> .resolveVariable(FacesContext.getCurrentInstance(), name);
>
> All that, just to find my session scoped managed bean? Or am I making
> it way more complicated than it needs to be? I *really* miss
> 'session.getAttribute()' right about now...
How do *you* know that it's a session scoped bean (versus perhaps being in
some other scope)?
How do *you* know whether it's been created yet, or whether it might get
created on demand (as a result of this evaluation) as a managed bean?
There's more to getBean() than just resolving a reference to an existing
session scope attribute, and Shale has an analogous method in its base class
that should really be used here :-). If you want simpler -- but still
portable between webapps and portlets -- go with:
FacesContext.getCurrentInstance
().getExternalContext().getSessionMap().get(name);
but you give up on the bean being in *any* scope, and being created on
demand.
If you really really want a session scoped attribute in a webapp, you can do
that too:
HttpSession session = (HttpSession) FacesContext.getCurrentInstance
().getSession();
return session.getAttribute(name);
--
> Wendy
Craig
Re: [shale] mailreader question
Posted by Laurie Harper <la...@holoweb.net>.
Wendy Smoak wrote:
> This is probably a JSF question, but I'm already here. :)
>
> MailReader's BaseViewController has:
>
> protected Object getBean(String name) {
> FacesContext context = getFacesContext();
> return context.getApplication().getVariableResolver().
> resolveVariable(context, name);
> }
>
> protected FacesContext getFacesContext() {
> return FacesContext.getCurrentInstance();
> }
>
> Unwinding everything, I get:
>
> FacesContext.getCurrentInstance().getApplication()
> .getVariableResolver()
> .resolveVariable(FacesContext.getCurrentInstance(), name);
>
> All that, just to find my session scoped managed bean? Or am I making
> it way more complicated than it needs to be? I *really* miss
> 'session.getAttribute()' right about now...
Heh :-) Actually, IIUC if you're sure the bean has already been created
you *can* do session.getAttribute() instead. But if you don't have that
guarantee you need to write more code... I can see why that helper
method exists!
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org