File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Other Open Source Projects and the fly likes Bear's Frontman, suggested way to pass a session object. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Products » Other Open Source Projects
Bookmark "Bear Watch "Bear New topic
Author

Bear's Frontman, suggested way to pass a session object.

Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

I'm making progress, and I know that there are no "rules" but there must be some wisdom that I can apply.

I'm writing a registration wizard. So I have code roughly like

1) servlet1 "forwards" to view1
2) view1 jsp uses bean1 to populate the form with FORM going to
3) servlet2 which validates input, and either forwards to view for the next step (view2), or if there are errors, forwards back to view1
4) view2 uses bean2 to populate the form with FORM going to
5) servlet3 which validates input, and either forwards to view for the next step (view3), or if there are errors, forwards back to view2
6) continue until done.

The problem is that I don't see a clean way to pass the session (or "CommandContext") to the beans, which is how they can easily get
access to the HttpServletRequest and then getting the session.

Normal JSP code calls the public constructor of the Bean, with no arguments.

I could put in a scriptlet that gets the request, something like:
<% rs2.initialize(request); %>

but that breaks the karma of scriptless JSPs.

Help
Thanks
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60748
    
  65

I guess I'm not really seeing the issue. 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. That's the whole point of the session -- it's the way to maintain data across requests without having them "hooked up" to each other in any way.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

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. .

I must be missing something fundamental. The bean has no access to the session.

At least without adding the scriptlet code, which I thought was bad form.

The view JSP just accesses its bean, and I don't see anything connecting the bean to the session.

What am I missing?
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60748
    
  65

All JSPs have access to the request, and therefore the session. You can pass info to the bean using <c:set> if you'd like.

But it almost sounds to me like you are doing setup in the JSP that belongs in the controller.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

Let me be more explicit.

For years, I've had code in my JSP like:

<% rs2.initialize(request); %>

Which looks like a scriptlet. I thought the goal was to not use scriplets.

Can you please give me a few lines that pass the request in to the bean without using the code style that I've been using, what you called "model 1" back in your article.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60748
    
  65

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:

which calls the setPageContext() injector of the bean with the page context instance.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

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:

Thanks for the code fragment.

I don't understand what you mean by setting it up in the controller.

What's the controller? I've got beans, views (.jsps)

Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60748
    
  65

In the case of Front Man, the commands serve as the controllers.

Have you glanced at this article? It explains the genesis of Front Man.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

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.

Yes, many times. And it shows FrontMan as the main controller in a classic MVC model. And most implementations of the classic MVC seem to smash two of the parts together.

In my code, which looks like:



which are beans by any other name. They are the beans that provide values (setFoo()) code that accept the FORMs in the JSP.

In the JSP, there is code looking like:



Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60748
    
  65

Hmmm, instantiating a command in a JSP. Not something I anticipated...
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

Bear Bibeault wrote:Hmmm, instantiating a command in a JSP. Not something I anticipated...


I am not following you well enough to know if that is what I'm doing or not. At the top of this thread, I clearly (or at least I tried) to exactly explain what I'm doing.

There is a Bean that is a @FrontmanCommand command. And its glued into a JSP so the JSP can just do trivial getters on the properties.

I'm not sure what else one would do.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60748
    
  65

Commands usually don't have any properties to get and set. They usually serve as page or task controllers. Their function is to receive requests, do whatever it is they are supposed to do, and forward onto the next resource -- usually a JSP serving as the view, or sometimes another command (a task controller will forward to the page controller for the page to be displayed, for example).

The JSP has no notion of the commands -- any data they need are set into the request as scoped variable by the page controller.

Doubling up a command to also serve as a bean is something I don't really see the utility of.

You mentioned Model 1... you aren't trying to set up a Model 1 construct using Front Man, are you?
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

Bear Bibeault wrote:You mentioned Model 1... you aren't trying to set up a Model 1 construct using Front Man, are you?

No, I'm trying to build a simple wizard. I'll add anything I need.
I just want some trivial JSP that have forms that go from one to the next, with server side editing, saving to the DB, etc.

I'm going crazy. This is supposed to be damn trivial. But I'm not getting it.

JSP has form, posts to X,
X does editing, and if cool, saves to DB, goes to next JSP
next JSP has Form, posts to Y

I can't believe this is complicated. But I sure can't figure out how to do it,
and clearly my efforts in this thread are not explaining (a) what I'm trying to do and (b) what I'm trying and
(c) why it fails.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60748
    
  65

It is actually pretty simple, once you grok it that is. The cycle is usually along the lines of:

1) User requests a page by hitting a URL that invokes the page controller (a command).
2) The page controller does anything that the page needs (fetches data from the model, etc) and sets the data on the request as scoped variables.
3) Page controller forwards to JSP which uses JSTL/EL to display the page.
4) User interacts with page and submits to task controller (another command).
5) Task controller does its task and decides where to go next. Invokes page controller for next page.
6) Go to (2)

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.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

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


I assume that after I can get registration wizard working, I can actually write some code that actualy does stuff. Might even use commands.

There really isn't much to control in the registration steps,




Bear Bibeault wrote:
2) ... sets the data on the request as scoped variables.
.


"Scoped variables" is a term of art that is not familiar.
I assume these are the bean variables access with getters and used in the JSP using EL references

getFoo() in the Java code

${bean.foo} in the EL
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60748
    
  65

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().

The command "sends" data to the view by setting request-scoped variables (or session-scoped if they need to hang around longer than the request).
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

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().
.

Thanks for the explaination/clarification
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Bear's Frontman, suggested way to pass a session object.
 
Similar Threads
is there any funtion in jsp like server.transfer in asp
form validation
Forwarding to a view on action in Liferay
page expired when clicking back button of browser.
HttpServletRequest API