Bear Bibeault wrote: Each request that goes through the CommandBroker gets its own commandContext, but that's fine. Even without the command context, the session obtained from the current request will be the same one that you dealt with in the previous request. .
Bear Bibeault wrote:Well, I'd probably usually take care of such things in the controller before even getting to the JSP, but when I do need to feed a bean the JSP environment:
Bear Bibeault wrote:In the case of Front Man, the commands serve as the controllers. Have you glanced at http://www.javaranch.com/journal/200603/Journal200603.jsp this article? It explains the genesis of Front Man.
Bear Bibeault wrote:Hmmm, instantiating a command in a JSP. Not something I anticipated...
Bear Bibeault wrote:You mentioned Model 1... you aren't trying to set up a Model 1 construct using Front Man, are you?
Bear Bibeault wrote:In your wizard scenario it may be even simpler as you may not need a task controller until the end of the series of wizard pages
Bear Bibeault wrote:
2) ... sets the data on the request as scoped variables.
Bear Bibeault wrote:A scoped variable is an object (usually a bean for easy EL access) that is placed in one of the scopes (page, request, session, application) via setAttribute().
I'm sure glad that he's gone. Now I can read this tiny ad in peace!
Sauce Labs - World's Largest Continuous Testing Cloud for Websites and Mobile Appshttps://coderanch.com/t/722574/Sauce-Labs-World-Largest-Continuous