Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 3.1 RC2
    • Fix Version/s: 3.1.1
    • Component/s: Web
    • Last commented by a User:
      false

      Description

      Hi !

      In a controller method, i'm trying to put flash attributes while using a instance of RedirectView, and it doesn't seems to work.

      In ViewNameMethodReturnValueHandler, we have the following code to handle a redirect scenario (an also handle flash attributes):

      if (isRedirectViewName(viewName)) {
      	mavContainer.setRedirectModelScenario(true);
      }
      

      I think it's possible to add into ModelAndViewMethodReturnValueHandler something like

      if (mav.getView() instanceof RedirectView) {
      	mavContainer.setRedirectModelScenario(true);
      }
      

      Then we could write

      redirectAttributes.addFlashAttribute("flashMessage", "the message"));
      
      return new ModelAndView(new RedirectView("myview"));
      

        Activity

        Hide
        Rossen Stoyanchev added a comment -

        We could do that but is there any reason not to prefer this?

        redirectAttributes.addFlashAttribute("flashMessage", "the message"));
        return new RedirectView("myview");
        

        or:

        redirectAttributes.addFlashAttribute("flashMessage", "the message"));
        return "redirect:myView";
        

        The concern I would have is having multiple ways to specify additional (non-flash) attributes:

        redirectAttributes.addAttribute("name", "thisName");
        redirectAttributes.addFlashAttribute("flashMessage", "the message");
        return new ModelAndView(new RedirectView("myview"), "name", "thatName");
        
        Show
        Rossen Stoyanchev added a comment - We could do that but is there any reason not to prefer this? redirectAttributes.addFlashAttribute( "flashMessage" , "the message" )); return new RedirectView( "myview" ); or: redirectAttributes.addFlashAttribute( "flashMessage" , "the message" )); return "redirect:myView" ; The concern I would have is having multiple ways to specify additional (non-flash) attributes: redirectAttributes.addAttribute( "name" , "thisName" ); redirectAttributes.addFlashAttribute( "flashMessage" , "the message" ); return new ModelAndView( new RedirectView( "myview" ), "name" , "thatName" );
        Hide
        R1B2 added a comment -

        The reason is that the signature of the methods returns a ModelAndView class, on a condition I have to do a redirection, and on another one I just have to return a ModelAndView. I could replace it by a String, but I think it's strange to have two different behaviors with:
        "redirect:myView"
        and
        "new ModelAndView(new RedirectView("myView"))"
        for the flash attributes and the redirect scenario. This is why I'm proposing it.

        Show
        R1B2 added a comment - The reason is that the signature of the methods returns a ModelAndView class, on a condition I have to do a redirection, and on another one I just have to return a ModelAndView. I could replace it by a String, but I think it's strange to have two different behaviors with: "redirect:myView" and "new ModelAndView(new RedirectView("myView"))" for the flash attributes and the redirect scenario. This is why I'm proposing it.
        Hide
        Rossen Stoyanchev added a comment -

        Yes, you are right that RedirectAttributes should be used when a redirect is requested regardless of the return value type. We'll review the ModelAndViewMethodReturnValueHandler and also the ModelAndViewResolverMethodReturnValueHandler.

        Show
        Rossen Stoyanchev added a comment - Yes, you are right that RedirectAttributes should be used when a redirect is requested regardless of the return value type. We'll review the ModelAndViewMethodReturnValueHandler and also the ModelAndViewResolverMethodReturnValueHandler.

          People

          • Assignee:
            Rossen Stoyanchev
            Reporter:
            R1B2
            Last updater:
            Trevor Marshall
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              2 years, 16 weeks, 2 days ago

              Time Tracking

              Estimated:
              Original Estimate - 10m
              10m
              Remaining:
              Remaining Estimate - 10m
              10m
              Logged:
              Time Spent - Not Specified
              Not Specified