Closed chkal closed 9 years ago
Comment by Santiago Pericas-Geertsen:
JAX-RS defines 4 possible return types for method, one of which is an extension point:
(1) void
(2) Response
(3) GenericEntity
(4)
Option (4) requires a MBW for which about a dozen ones are provided out of the box.
For MVC, at the very least we should support:
(1) void: In which case the view (template) must be specified declaratively using @View (2) String: where the path to the view is returned as the value of the method (3) StreamingOutput (or equivalent): for those applications that want full control of the output stream. For example, applications that use view engines requiring a compilation step.
What about a Response type? This type will give full support to set headers, etc. but doesn't seem to fix MVC that nicely. TBD.
Comment by Santiago Pericas-Geertsen:
At first glance, there doesn't seem to be a need to restrict parameters in a controller method. Everything that is supported for JAX-RS should be available.
Comment by Santiago Pericas-Geertsen:
Only void and String are treated specially at the moment. The former intended to be used with @View.
Comment by Santiago Pericas-Geertsen:
See specification.
Original issue MVC_SPEC-8 created by Santiago Pericas-Geertsen:
The signature of a resource method in JAX-RS is open ended: various return types are supported, any number of parameters can be injected, and HTTP entities can be bound as un-annotated params.
MVC will likely restrict these signatures, especially return types given that a controller method is expected to generate HTML representations, likely with the aid of a templating system.
The anatomy of an MVC controller method needs to be defined.