View support should change to be same as JSON marshalling result, with view annotation about nubes

[aesteve]

Wow, a lot of things here. Let me try to clarify, since I'm not really sure I understand all of your points.

1. "ModelAndView"

I'm not sure what you mean by "view objects at the top level" along with Vert.x's template engines.

All templates engines implementations rely on a Map as a "view object" if I'm not mistaking. And this map is RoutingContext.data(). There's no "ViewObject" the same way Spring has "ModelAndView". So, what would you expect for handling a @View annotated method's return ?
Just adding the return object to context.data() (or putAll if's a map) ? But under which key ?

1. Same method for both a view and a REST call

I understand your use case but never faced it myself actually. (I designed Nubes from my actual needs since I had to start with something :\ ). Is this a pattern you're writing quite often ?

And more important : do you think having what you wrote (same method, two content types) is more readable than having two separated controllers relying on the same method (DAO for instance) under the hood ? (it's not a rhetorical question, I'm actually interesting in the answer :) )
In my applications, REST API calls are often mapped under /api/{version} which wouldn't allow me to write what you did in your example.

1. &format=json

Two different things here.

• first : allowing to force some content-type when several content-types are available on a route, without having to deal with your Accept header. A lot of frameworks/interceptors actually allow this (RESTEasy iirc). If /some/path is annotated with @ContentType({"application/json", "application/xml"} then /some/path.json should only return JSON. It's not what you're asking for but that's something I had forgotten, I'll open an issue for that and thanks for reminding me about this :)
• then : I understand your use case which applies perfectly to Spring's ModelAndView. It would work like a charm in this context. But how would you do with Vert.x-web template engines ? Returning context.data() ?

Thank you.

[apatrida]

I'm actually not sure jaja. We have moved away from views in the app and do most client-side now. But we have some that are both API + View from same endpoint because it is the same action for us with a different output format. That is less of the issue I was really intending to address, than having it be such a different style of data.put() or data.add() instead of just returning the model for the view. Freemarker for example can use an object as a model and not just a map. With a comment in the view, you then have typesafe editing in IDE's such as Intellij IDEA. Having only a map as the data model is not what everyone wants.

[villesau]

I actually also noticed the way to use views. I would always avoid to put data to passed in variables, but just return the data instead. It's clearer and more convenient way to do it. i never modify the objects what have been passed into the method. The idea of @view("viewname") was also pretty nice imo. btw the project looks really nice, great work! :)