> -----Original Message----- > From: Aaron Bartell [mailto:[EMAIL PROTECTED] > Subject: Re: Critique implementation of managed bean access > >If you don't want to use container-managed authentication & > authorization, I'd implement a filter to do that. So the app > wouldn't need to do any extra checks for basic authorization anymore. > I actually implement isLoggedIn in a PhaseListener which then > gets called every request for PhaseId.RESTORE_VIEW. Is this > the type of filter you are talking about?
No... I'm talking about standard plain servlet filters as defined in the servlet spec 2.3. The PhaseListener only works inside the JSF lifecycle, but if you need to authorize a non-JSF requests as well, a filter is the next-best option to container manager authorization and has some other benefits. > >If you need to access some other bean in a bean, why not > make the other bean a managed property of the bean and let > the framework handle setting it for you? > Help me understand what you are saying. Do you mean every > bean would have a getter/setter for any other managed-bean it > needs access to? So if bean1 needed access to beans b1, b2, > b3, b4,b5,b6 and b7 I would have to create property accessor > methods for each of those? Yes, that's essentially what I'm saying, though you don't need to call them yourself, but the framework would do it for you as Heath explained. Of course, if you really need to have references to seven beans you could put the accessor methods in a superclass, but somebody might argue that there's something wrong in your design if you need references to seven other beans in all of other beans. > >And isLoggedIn() sounds like it should semantically be an > operation of User object. > > I have mixed feelings on that, because User is my Model > object and there will be many instances where a property > called loggedIn just wont make sense, but it is a perfect fit > for a class called LoginController. See my point? I didn't > post the User object, but it is basically hibernate generated > with some ease-of-use accessor methods built in. Maybe.. I got a lot of ideas when I read Craig's Shale proposal. Anyway, User backing bean could be just a wrapper to User model object and could handle some additional UI interaction - after all, the name "backing bean" probably wasn't only coincidental. Kalle
