Announcement Announcement Module
No announcement yet.
Referencing RequestMappings from JSPs Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Referencing RequestMappings from JSPs

    I am using Spring MVC with JSPs. My project is still undergoing many changes, so request mappings are changed often. However, when a request mapping is changed, we end up with broken links if we don't find and update every JSP that has a link to the changed request mapping.

    Here's an example:

    @Controller @RequestMapping("/login")
    public class LoginController {
        public String getMainLoginPage() {...}
        @RequestMapping(value="/{domain}", method=GET)
        public String getDomainLoginPage(@PathVariable("domain") String domain) {...}
        public String login(@Valid LoginForm form) {...}
    <a href="${pageContext.request.contextPath}/login">General Login Page</a>
    <a href="${pageContext.request.contextPath}/login/whatever">Whatever Domain Login Page</a>
    Let's say, from the example above, we changed the request mapping for getDomainLoginPage() to "/login/to/{domain}". What can be built or modified to have this change automatically reflected in the JSP?

    I have an idea on how to do this, but I'm hoping there's a less manual way of doing this with Spring MVC. Here's my idea:

    1. Define all request mapping paths as static final Strings. Use the constant Strings in the Controller @RequestMapping annotations.

    2. Create a static method for every request mapping. The method uses the corresponding static final String from point 1. The method signatures allow values for path variables and query params to be passed in. The methods return the generated URI string.

    3. Create a taglib around the static methods and use the String. Use the taglib from the JSP to build URIs.

    The problem with my idea is that it requires manual maintenance of the static methods and taglib. Perhaps there should be a way to name each request mapping, via a "name" parameter in the @RequestMapping annotation. Then some functionality can be built around allowing JSPs to reference a request mapping by name rather than having to hard-code the path.

    What are your thoughts/opinions on this?

  • #2
    or you could have a properties file?
    ${controllerPaths['login']} ?
    or something like that.


    • #3
      Originally posted by titiwangsa View Post
      or you could have a properties file?
      ${controllerPaths['login']} ?
      or something like that.
      Hi titiwangsa,

      I like the idea of a properties file instead of a bunch of constant string fields...However the @RequestMapping annotation requires the value of the mapping to be known at compile time (i.e. constant strings).

      If the @RequestMapping annotation allows specifying a name for the mapping, we might be able to just hard-code the path into the @RequestMapping and get a map of paths from a custom HandlerMapping implementation to use in either the taglib functions or directly in the JSP. For example:

      @RequestMapping(name="loginPage", value="/login", method=GET)
      public String loginPage(ModelMap model) {
          model.addAttribute("controllerPaths", RequestHandler.getMappedPaths());
          return "login.jsp";
      public static final String loginPage() {
          return RequestHandler.getMappedPaths().get('loginPage');
      <%@ taglib prefix="ex" uri="" %>
      <a href="${controllerPaths('loginPage')}">Login here</a>
      <a href="${ex:loginPage()}">Or here</a>
      If we changed the mapping from /login to /signin, as long as we keep the name constant, the JSP links will not break. However, this only adds another layer of abstraction that does not offer any protection if the mapping is removed or the name changes (JSP links will be broken and won't be reported by compilers).

      I am hoping to either:
      1. Have a single place where paths are defined that is referenced by controllers and JSPs. It would be great if that same place is able to encapsulate request param data and all other request-mapping related stuff.

      2. OR somehow enable checking of path references in JSPs at compile-time or jsp-compile-time. I think having a taglib that generates URLs sort of fills this capacity if the query params change.



      • #4
        Seems like there's a JIRA ticket open related to this:

        Also, found a possible solution (need to look into it more to determine if it's adequate):