This is the basic architecture of my web-applications. I have a dispatcher that receives requests. Each requested URL has an "action" parameter that tell the dispatcher which Action object to use for execution.
I like it very much and i think it's the "standard" way. But, i don't like that when i do some tasks like "deleteSomething", or "addSomething".... it gets executet as many time, as i hit Refresh button from the browser.
I've read Bear's article about PRG technique, but i face other problems now, like errorReporting, that i used to put into the request object. Another problem is that Action.process() method always return a Page (implemented by myself) that contains the path to o JSP that gets forwarded. Using PRG technique i have to return from process method two kind of objects: either a path to a jsp in application, or a relative(or absolute) URL for redirecting. So, i have to check and decide: to redirect, or to forward?
Advice me please, how to implement this technique in a better way.
If you think you've done too much, usually it means you've done too few.
That is correct. Your action decides whether it is repainting the form with an error message or the "result" page (which is the redirect.) Typically these actions are called "failure" or "success."
Yeap, but could you please give me an idea?
Till now, my action classes returned just a Page(that incapsulates a String) - a relative file path of the jsp on the server and i just forwarded to this jsp. Now, situation changes and i can return either a Page, either a piece of URL (for redirect). So, i have to types of actions: one that returns a Page(a string containing jsp path to forward to), another one that returns a piece of URL(to redirect to). I can't find the best architecture solution... take a look, please, at my controller and advice me how to refactor in order to manage redirects, as well.
It seems like the redirect/forward decision needs to be encapsulated in the Page somehow. For example, in S1 the ActionForward had a "redirect" boolean configured in XML, Struts 2 has different result types, including a dispatcher (forward) or redirect. So when you determine the Page object being returned you'd also have to decide which it is, a forward or a redirect, and encode that in the Page.
The Page processor does the right thing based on whether it's a redirect or forward.
There aren't too many options for maintaining data across a redirect: you either keep it in session (even if only for a single redirect, like Rails' "flash" concept), keep it in a thread local (for singleton controllers, but prone to bugs, IMO), or... not sure what other easy solutions might be.
Joined: Jan 03, 2009
Yes...session is a good solution. The only think i don't like is that i have to remeber to remove attributes from session at the bottom of each .jsp.
You don't, although you can. I don't think a JSP page should be used to control the lifespan of server-side objects, but that's just me. If they're short-lived objects, again like Rails' "flash" scope (they live for a single redirect) then they could be cleared out in a filter or similar framework mechanism.
Joined: Jan 03, 2009
Usually, JSP is the last step in a request lifecycle..... am i right? Is it possible to set a filter somehow after the final jsp to clean the session? It's not a problem, actually, to do it at the end of each view, but on the other hand, it's not the business of view.
Filters can wrap requests (that's how GZip filters work, for example--after the response data is available they gzip it up).
I've not actually implemented this functionality with a filter, I've always done it within whatever framework I'm using, but since you can run code and modify things after the filter chain executes I don't see why it wouldn't work.