If you’re me, and you finally get some code working, the last thing you want to do is restart your computer and see if it’s still there. I think the key to getting over this kind of fear is understanding the logic, the science, the brains behind the magic that makes code compile. Here is the first of a handful of technical expository posts on what I’m learning this summer, compilations of insight I gained by reading OpenMRS wikis, asking mentors, other OpenMRS developers, or Creighton experts, and Google-ing. This one is about all of the possibilities I discovered for getting from one Java Server Page to the next, and back again.
This might seem obvious, which is why beginners run the risk of over thinking it. The link can send the user anywhere and be styled to look like a button. Data can follow a link to the next page in your web app by using a cookie or setAttribute() of a session or request.
<a href="fortuneCookie.form">Read my fortune</a>
In this example, fortuneCookie represents a .jsp file, but my web app is happier with the .form extension. You might use .jsp, .form, .list, .htm, or something else, and results may vary.
Add an action to a form tag. When the form is submitted, the user is taken to the page specified by the action. For example:
<form action="fortuneCookie.form" method="POST"> ... </form>
If a controller is also being used, methods can be annotated with “@ModelAttribute” and have parameters “@RequestParam(“fortuneCookieId”)” where fortuneCookieId is a form field determined These methods are processed first so their data is available.
Have a submit button that submits to a controller. If the button has a name and value, the controller that accepts the post can check if the name and value of a particular submit button exists and then redirect to a different page. The method used to redirect may return a String and if the button was clicked, return “redirect:fortuneTeaLeaves.form”; That should work.
With annotation-driven Spring MVC, you can use something like “@RequestMapping(“/module/fortunetelling/fortuneCookie”)” to annotate a method in a controller so it is called every time that page is requested.
Within the one controller, I have many, small, explicit methods. One advantage of having multiple methods with clear intentions is that they are easier to test than one method with multiple steps to follow. One method might be helpful if you need very similar behavior for each request.
From what I can tell, using multiple controllers named after different pages is an alternative to annotation driven Spring MVC and a viable option if you have multiple data sources or “models.”