Managing page flow in Play! framework tags

Question

In a web app built using Play framework, I have a checkout page which lists the user's shopping cart as well as an address form. I created the address form as a tag (addressform.html) so that it can be reused.

checkout.html:

#{if shopcart.cartItems}
    #{shopcartview customer:customer,shopcart:shopcart/}
    #{addressform customer:customer /}
#{/if}

The address form has a form element #{form @setAddressInfo()}

which calls a controller method as below

public static void setAddressInfo(Long customerId,...) {
   ...
   showPaymentPage();
}

which if everything went well, goes to a payments page.

The problem occurs when I want to reuse the addressform on my confirmOrder page.

confirmOrder.html:

#{if shopcart.cartItems}
        #{shopcartview customer:customer,shopcart:shopcart/}
        #{addressform customer:customer /}
#{/if}

<a href="link_to_payment_page">editPaymentInfo</a>

here, if the user changes the address and submits the form, the setAddressInfo() method will, on successful completion open up the payments page. That is not good--the user may not want to change the payment info at all. Also, I am providing a link to payments page for those users who want to change payment info. I want the same OrderConfirm page to show up, so that the user can click on the Submit Order button.

So how do I do it? I can surely reuse the address form in this case right? Can you help me figure out how to manage page flow in this case?

Answer 1

You can provide a parameter, indicating where to redirect the user, to the setAddressInfo() via hidden input or via java paramater like. Both options:

<input type="hidden" name="urlToRedirectUserTo" value="urlToRedirecTo(maybe using @{}..)"/>

Or:

#{form @setAddressInfo("urlToRedirectUserTo")}

And in the action you do:

public static void setAddressInfo(String urlToRedirectUserTo) { 
   ...
   ...
   ...
   redirect(urlToRedirectUserTo);
}

There are better options to make it more typed and less error prone, but this one is probably good enough.