Fallback behavior for controllers with unsupported return types

chkal commented 9 years ago

Original issue MVC_SPEC-37 created by Christian Kaltepoth:

Currently the spec allows void, String, Response and Viewable as return types of controller methods. The spec doesn't specify what should happen if a controller method declares some other return type.

I think it would be very nice if we provide some kind of fallback behavior in cases where controller methods have some other return type. IMO we could for example specify that in this case the implementation has to call toString() on the result and process it as a view name. This would open the door for some interesting ways of extending the default behavior:

Use Java enums for type safe navigation like implemented in Apache DeltaSpike and its type safe view config
The use of builder-like classes that provide a more fluent way to build view names and/or redirection URLs.

IMO such a fallback behavior is much more useful than throwing an exception at deployment time.

chkal commented 9 years ago

Comment by Santiago Pericas-Geertsen:

See revision,

https://java.net/projects/mvc-spec/sources/git/revision/8e339334102609438cb98007a809a3733f17be18

chkal commented 9 years ago

Comment by Santiago Pericas-Geertsen:

Spec document updated.

chkal / mvc-spec-migration-test

Fallback behavior for controllers with unsupported return types #37