Results 1 to 9 of 9

Thread: The introduction of SmartView in spring-webmvc 3.1

  1. #1
    Join Date
    Mar 2007
    Location
    Amsterdam
    Posts
    18

    Question The introduction of SmartView in spring-webmvc 3.1

    In an existing application I use the ContentNegotiationViewResolver to provide both xml and html responses. For some html requests, the response should be a redirect, where for xml it should use a MarshallingView.

    Previously this worked perfectly. However, with the introduction of the SmartView interface and the adjustment to ContentNegotiatingViewResolver.getBestView(..) this is no longer working.

    What could be the workaround to get this working?

  2. #2
    Join Date
    Aug 2006
    Location
    Brooklyn
    Posts
    556

    Default

    There was a fix in 3.1:
    https://jira.springsource.org/browse/SPR-8611

    where if the view string begins with "redirect:" the redirect was being ignored when using the ContentNegotiatingViewResolver.

    Can you provide some more detail on your case?

  3. #3
    Join Date
    Mar 2007
    Location
    Amsterdam
    Posts
    18

    Default

    Apparently, we make use of the opening that was in the ContentNegotiatingViewResolver.

    We have a parent-child view, where if you request the child as xml, you get xml. And when you request the child as html, you get a redirect to the parent.

  4. #4
    Join Date
    Aug 2006
    Location
    Brooklyn
    Posts
    556

    Default

    Would you mind posting what the controller method looks like?

  5. #5
    Join Date
    Mar 2007
    Location
    Amsterdam
    Posts
    18

    Default

    That would be very simmilar to this.

    Code:
    @RequestMapping(value ="/{parentName}/{childName}", method=RequestMethod.GET)
    public void doGet(Model model, 
                            @PathVariable("parentName") String parentName,
                            @PathVariable("childName") String childName) {
        DomainObject o = callSomeService.getObject(childName);
        model.addAttribute("object", o);
    
       return "redirect:/" + parentName";
    }

  6. #6
    Join Date
    Mar 2007
    Location
    Amsterdam
    Posts
    18

    Default

    Does anyone know a way to solve this?
    Do I need to remove the ContentNegotiationViewResolver?

  7. #7
    Join Date
    Aug 2006
    Location
    Brooklyn
    Posts
    556

    Default

    If you rely on the 'Accept' header you can have:

    Code:
    @RequestMapping(value ="/{parentName}/{childName}", method=RequestMethod.GET)
    public String doGet(Model model, 
                              @PathVariable("parentName") String parentName,
                              @PathVariable("childName") String childName) {
        DomainObject o = callSomeService.getObject(childName);
        model.addAttribute("object", o);
        return "redirect:/" + parentName";
    }
    
    @RequestMapping(value ="/*/{childName}", method=RequestMethod.GET, produces="application/xml")
    public DomainObject doGetAsXml@PathVariable("childName") String childName) {
        return callSomeService.getObject(childName);
    }
    The doGetAsXml method doesn't specify a view name because I assume you have MarshallingView as a default view in the ContentNegotiatingViewResolver. Not the only way to do it but to me it is a little more clear at the cost of some brevity.

  8. #8
    Join Date
    Mar 2007
    Location
    Amsterdam
    Posts
    18

    Default

    Hey Rossen

    I've tried to test the produces option, but it seems to me that the AnnotationMethodHandlerAdapter acknowledge this attribute.

    I could try to change to RequestMappingHandlerAdapter, but I was wondering if their is an Adapter that would compare the produces attribute with the extention instead of the Accept header.

  9. #9
    Join Date
    Aug 2006
    Location
    Brooklyn
    Posts
    556

    Default

    Roald, the AnnotationMethodHandlerAdapter doesn't support the produces option. If you're on Spring 3.1 I recommend using RequestMappingHandlerAdapter, which also implies use of RequestMappingHandlerMapping and ExceptionHandlerExceptionResolver instead of (DefaultAnnotationHandlerMapping and AnnotationMethodExceptionResolver).

    As for using relying on the extension, it is planned, see SPR-8410.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •