Speaking of our noddy MVC framework, it's all coming together now.
The bleedin' obvious stuff: we have a Controller servlet, to which all *.command URLs map. The Controller loads up a Map when it starts up, mapping URLs to Actions. An Action consists mainly of a class implementing an interface; ControllerAction. The Controller instantiates this class, and calls its doAction() method. The request and response objects are passed into this method, giving the Action access to everything that it needs.
So far, so good. But this is where is starts to get a little complex. What happens next?
We need to redirect (or forward) the client on to the View, usually a JSP, at this point. But we'll need to pass some information from the Action to the View. How do we do this? We are just returning a ControllerActionResult object from our ControllerAction.doAction() method, and stuffing this into our session. This is working so far, but I'm worried.
Also, to which View should we redirect? Initially, we were just going to keep this in the Controller's Action mapping, but of course, you might want to redirect to different JSPs depending on what the Action thinks. Do you just have a fixed number of potential target Views? Say, one for a successful Action, another for a used error, and another for an unexpected error? What if you need more options than this?
At the moment, our ControllerAction.doAction() method is passing back the target View as an attribute of the ControllerActionResult object, and we redirect according to this. This works OK, but will it scale?
Oh, BTW, we have decided that we will use JSTL's SQL taglib to present our financial data. To our application, it really is just a bunch of numbers, so building a Model is just unnecessary work. YAGNI. ;-)
Posted to Java by Simon Brunning at February 10, 2004 04:45 PMBeen thinking about these issues just recently.
Unless you are very sure of your requirements, its a good idea to allow an Action to display an arbitrary number of successful pages. Most actions will have only one exit, but they pop up in surprising places. Stupid example: on a registration form, if user ticks the 'send me info by email' box, then the application needs to display a page to ask for email address, otherwise it continues onto the 'success' page.
JSPs are servlets, but making JSPs directly accessible to users on a public web-site is asking for trouble. If a user types the URL of a JSP into their browser, what data will you use to render it? So, redirecting to JSPs is a no-no, unless you're writing an intranet app for a trusted environment.
Just my $0.02 worth.
Posted by: Alan Green on February 11, 2004 12:22 AMFull bookmarkability is a requirement of our system, Alan. Our JSPs check that they have all the context that they require.
Almost always they do, in fact. Our systems is pretty simple, and most of the required context comes from the fact that the user has signed in. (We use a Filter to make sure that they are. If not, we store the requested URL, take them through a log-in page, and redirect to the initially requested URL once they've signed on OK.)
If they don't, well, the JSP just redirects them back to another JSP. I know this hard-cose some screen flow into our JSPs, and that this is A Bad Thing, but as I say, there isn't much of this in our system at all.
How else could we do this, bearing our full bookmarkability requirement in mind?
Posted by: Simon Brunning on February 11, 2004 11:05 AMWe've just added something to extend our bookmarkability somewhat. Where we *expect* to need context, where that context is transient, and where we want that context to be bookmarkable, we put it in a query string rather than storing it in the session.
For example: the user is able to look at some financial data. (See JSTL SQL justification above. Or is that rationalisation? :-) They are only able to look at their own data, so *that* part of the context is stored as they log in. But they can also supply selection criteria - only this year's transactions, only transactions over a thousand quid, that sort of thing. We will put these into a query string in the URL, so the user can bookmark specicic queries.
Posted by: Simon Brunning on February 11, 2004 12:53 PMJust an aside on directly showing JSPs, on stuff I have worked on we don't have the JSPs in the webroot so you have to go through the controller to do anything.
The net effect is that nobody ever gets tempted to just use a JSP for a "simple static page" as it simply won't work.
Agreed that on simple sites this is probably overkill though.
Posted by: Darren on February 12, 2004 01:50 PM