Define SPI for hooking into the view resolution

[chkal]

This issue is about starting some first discussions about defining a SPI for hooking into the view resolution. This idea was brought up by @jslsolucoes as part of #126.

The idea is to have something like:

public interface ViewResolver {
    Viewable resolve(ViewResolverContext ctx);
}

public interface ViewResolverContext {
  Object getControllerResult();
  ResourceInfo getResourceInfo();
  // ....
}

This would for example allow to automatically derive the view name from the controller class/method name. Of course in this case the default implementation should be moved into an implementation of that interface. This will also require to add some kind of ordering or a chain like processing so that custom implementation can access the result of the default algorithm.

Feel free to share your thoughts.

[erdlet]

Generally I like the idea and think we should add it, because it helps people using Krazo to add different ways of view resolution and us too, as we can simplify the ViewResponseFilter.

Regarding the spec, the only ViewResolver which needs to fulfill the requirements to controller methods is our default implementation, right?

[chkal]

@erdlet Yes. This is how we could implement it. Basically it would be similar to the LocaleResolver API which also provides a default implementation but which can be overwritten by a custom resolver. It will become more interesting if we want to support the scenario where a custom resolver can only provide a viewable for some controllers but should also be able to fall back to the default implementation.

[erdlet]

... where a custom resolver can only provide a viewable for some controllers but should also be able to fall back to the default implementation.

This reminds me of the MvcConverter#supports method. Maybe we can add something similar in the ViewResolver?

[chkal]

Possibly yes. IMO the SPI implementation should get as much information as possible.