Post-Request-Get technique

[Vadim Vararu]

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.

[Jeanne Boyarsky]

Vadim,
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."

[Vadim Vararu]

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.

package com.atnt.controller;

//imports here

public class Frontend extends HttpServlet {

    private HashMap<String, IAction> actions;
    private IAction defaultAction;

    protected void doGet(HttpServletRequest request,
            HttpServletResponse response) throws ServletException, IOException {
        process(request, response);
    }

    protected void doPost(HttpServletRequest request,
            HttpServletResponse response) throws ServletException, IOException {
        process(request, response);
    }

    public void init() {
        actions = new HashMap<String, IAction>();

        // SHOW ACTIONS
        ShowCompetence showCompetence = new ShowCompetence();
        ShowCustomer showCustomer = new ShowCustomer();
        //...and many other action object....


        // PUT ACTION OBJECT IN THE MAP
        actions.put(showCompetence.getName(), showCompetence);
        actions.put(showCustomer.getName(), showCustomer);


        // SET DEFAULT ACTION
        defaultAction = showCustomer;
    }

    private void process(HttpServletRequest request,
            HttpServletResponse response) throws IOException, ServletException {

        String requestActionNameParam = request.getParameter("action");
        IAction actionToPerform = null;
        WebPage view = null;

        if (actions.get(requestActionNameParam) != null) {
            actionToPerform = actions.get(requestActionNameParam);
        } else {
            actionToPerform = defaultAction;
        }

        view = actionToPerform.perform(request, response);
        request.getRequestDispatcher(view.getTemplate().getValue()).forward(request, response);

    }
}

Here is an example of an action:

package com.atnt.action.backend;

//imports here

public class CheckAdmin implements IAction {

	public String getName() {
		return "checkAdmin";
	}

	public Page perform(HttpServletRequest request, HttpServletResponse response) {
		ErrorHandler errorHandler = new ErrorHandler();

		if (request.getParameter("nickname") == null || request.getParameter("password") == null) {
			errorHandler.addError(ErrorMessage.BE_LOGIN_NO_SUCH_USER);
		} else {
			String nickname = request.getParameter("nickname");
			String password = request.getParameter("password");

			User admin = UserDAO.readAdmin(nickname, password);
			if (admin == null) {
				errorHandler.addError(ErrorMessage.BE_LOGIN_NO_SUCH_USER);
			} else {
				request.getSession().setAttribute("currentUser", admin);
			}
		}

		return getPage(request, response);
	}

	private Page getPage(HttpServletRequest request, HttpServletResponse response) {
		//some logic to decide which jsp path to return
		return Page.SOME_VIEW;
	}
}

[Jeanne Boyarsky]

This is a Struts question. Moving to our Struts forum.

[Vadim Vararu]

Maybe this architecture is similar to struts', but i don't use struts.

[Jeanne Boyarsky]

See this article which contains an example using forwards in Struts 2.

[David Newton]

This has nothing to do with Struts; he's right.

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.

[Vadim Vararu]

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.

[David Newton]

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.

[Vadim Vararu]

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.

[David Newton]

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.