This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
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); %>
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.
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.
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?
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.
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.