Hi Devon,
> Using FreeMarker views is probably the best option, but probably lead to
very, very slightly more complicated Controllers.
In my experience, that's right. Generally, @ResponseBody controller methods
are meant for directly returning the object (in a REST-y kind of way),
while the traditional ModelAndView-type (non-@ResponseBody) methods are
meant for rendering the object with a view / template like Freemarker.
You *could* mix the concepts, e.g., by using a @ResponseBody controller
method to return an object for "Accept: text/html", and then using an
HttpMessageConverter to try to render it as HTML using a template. But I
think that would be inviting complexity in the wrong place -- Spring treats
the components as "orthogonal," like you said. The controllers would not
even be able to select an intended view, so the http message converter
would have to figure it out.
Keeping them separate costs one additional method, but to me at least, it
would be a more natural and clear use of the framework, and shouldn't be
any more complicated if the underlying logic is shared. It should also
cause fewer surprises down the line.
See an example here:
https://spring.io/blog/2013/05/11/content-negotiation-using-spring-mvc
(under "Combining Data and Presentation Formats").
One other note, while on the topic of serialization. We've been talking
about docs autogeneration tools that are based on introspection of the
framework annotations, like Swagger/Springfox -- but such tools will
generally not be aware of arbitrary serialization logic that happens
outside of the controller. I think some more research is required to figure
out how big the gap is between the actual results of an API call and what
those tools will be able to introspect.
- Matt
On Wed, Mar 15, 2017 at 2:58 PM, Devon Tucker <dtuc...@boundlessgeo.com>
wrote:
> > I think the geofence-server used spring mvc - could that be providing
> your conflict?
>
> Probably not. I don't have any community modules enabled.
>
> > Is there any documentation explains to look at for these two options?
>
> I'll try to compile the results of my research. Using FreeMarker views is
> probably the best option, but probably lead to very, very slightly more
> complicated Controllers.
>
> > Yes, we outlined that as part of the plan (it was one of the reasons we
> thought this was possible).
>
> It is possible. It's just not entirely clear on the details yet. XML and
> JSON serialization all have small bits of customization depending on what's
> being returned (see ReflectiveJSON/XMLFormat.java). Currently these
> customizations are part of the type hierarchy of the RESTlet resource being
> accessed which is where the wrinkle comes from. Response serialization in
> Spring MVC is fairly detached from the controller itself and more
> centralized. It's something that just needs more research, in particular
> documenting the various bits of customization that already exist.
>
> On Wed, Mar 15, 2017 at 10:57 AM, Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
>> Thanks Devon:
>>
>> That's about it. Just this raised a decent few questions and problems for
>>> me:
>>>
>>> - Right off the bat despite mapping my new endpoint to "/restng/styles"
>>> I found that it actually ended up being mapped to "/rest/restng/styles". I
>>> can't for the life of me figure out why that's happening. I tried removing
>>> the existing rest and restconfig modules from the project, removed the REST
>>> wrapper config and still had this issue. Maybe not a big issue in practice,
>>> since we want all the end points to be under /rest presumably, but it'd
>>> certainly be nice to know WHY this happens. Something to do with the
>>> AdvancedDispatchFilter maybe? (In fact after a little digging this seems to
>>> be the "culprit")
>>>
>>> - Conflicting Spring MVC contexts. I used the <mvc:annotation-driven/>
>>> directive to enable Spring MVC in my module. Then I added a new
>>> HttpMessageConverter (like this https://dzone.com/articles/customizing)
>>> to customize response handling. I could see the new converter being
>>> instantiated and added to the list of converters, however during the
>>> response cycle it was nowhere to be found. It seemed like internally there
>>> was another Spring context that was being used that had the default
>>> converters. If I remove the <mvc:annotation-driven> directive from my
>>> context then my new converter DOES get used though. This is interesting
>>> though because the only references to Spring MVC are in community.
>>>
>>
>> I think the geofence-server used spring mvc - could that be providing
>> your conflict?
>> - https://github.com/geoserver/geoserver/blob/master/src/
>> community/geofence-server/src/main/java/org/geoserver/
>> geofence/rest/RolesRestController.java
>>
>> - How should HTML responses be handled? Spring MVC RestControllers aren't
>>> really meant to return HTML. AFAICT the options are use the actual
>>> ModelAndView functionality with freemarker views, which would involve
>>> separate controller methods for HTML calls, or to create a new
>>> HttpMessageConverter to handle HTML requests. Both probably have issues.
>>> Creating a new MessageConverter is a little problematic, since these are
>>> centralized and orthogonal to the actual controllers. HTML responses in the
>>> current REST framework rely a lot on the type hierarchy of the RESTlet
>>> controller that handles the request. It's a little tougher to do it this
>>> way in Spring MVC because the response encoding happens outside the
>>> controller lifecycle.
>>>
>>
>> Is there any documentation explains to look at for these two options?
>>
>> My quick search found more examples of using freemarker views (and I
>> think we use freemarker elsewhere).
>>
>> - This seems a little more straightforward, but I assume we want to
>>> re-use all the existing XML/JSON serialization. This will require custom
>>> MessageConverters for those.
>>>
>>
>> Yes, we outlined that as part of the plan (it was one of the reasons we
>> thought this was possible).
>>
>>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
