2

A psuedo controller method

@RequestMapping("/foo")
public String getFoo(Model model) {
   model.add("foo", repo.findFoo());
   model.add("bar", repo.findBar());
   model.add("barOptions", repo.findBarOptions(bar));
   return "fooView";
}

Let's say the client uses Expression language to render foo and bar; but we use JavaScript to render barOptions.

<html>
    <script>
    var options = <mytag:toJSON object="${barOptions}"/>;
    $("#options").renderOptions( options );
    </script>
    <body>
        <mytag:renderFoo foo="${foo}"/>
        <mytag:renderBar foo="${bar}"/>
        <ul id="options"></ul>
    </body>
</html>

Common conventions tells me this is bad. But the essence of MVC, where the controller sends data and the view determines how to use it, tells me this is good. Is there a better way to do the same thing? Is there any reason why this isn't commonly done? I could request the JSON using a separate call, but then I have to make more requests for the page to load, and there may be logic to determine barOptions in the controller method getFoo() based on other input at the time of the page load.

walnutmon
  • 5,873
  • 7
  • 42
  • 57

2 Answers2

2

At first glance I can not say that I see anything blatantly wrong with approach. The only aspect that initially took me off guard was your need to convert data in the model object to json.

For me, JSON usually implies that there is some sort of server side object that needs to be converted so that a client side javascript can access or manipulate its structure in a javascript way. I guess without knowing more of the purpose of the options list, I can't see a reason why json serialization is required here.

By using a Tag to convert a model object to JSON, we avoid an additional request made by the client

But if we assume that JSON is a requirement (perhaps for some third party jquery plugin), then I absolutely do not see anything wrong with approach.

What is special or different about the barOptions unordered list, why does it have be rendered with json? Why not just use a for loop to build the list items? Or you can have a custom tag that builds out the ul entirely.

Aside from that, I missing the point as how one may perceive this as being bad code.

Roy Kachouh
  • 1,855
  • 16
  • 24
  • The reason I'd want JSON is to reuse the same code to generate how the options are viewed (assume an option and the rendering of them is more complicated than just a drop down) - when the page loads I will initially draw the component in JSP, then when something updates, I update the component with JS - it would be nice if I could use the same logic for both so if I change the way it's rendered I don't have to modify both the JS option component renderer and the JSP that initially renders the component – walnutmon Dec 14 '11 at 17:10
  • Ok, I see your point now. The renderOptions function will be leveraged not only on creation, but also on subsequent changes. That said, I think this seems to be an elegant approach. Plus, as you correctly alluded to, model and view are still separated and encapsulated in this approach. The view is acting on data from the model, how it is acting on it is not a concern for his sisters - model and controller. I also like the idea of having a custom tag that is responsible for converting an object to json. I might have to take that one :) – Roy Kachouh Dec 15 '11 at 17:53
0

Normally JSON is requested by JavaScript with an Ajax call, but if in your case it's available at page rendering time, I see nothing wrong with your solution. It's clean, compact code and easy to read. Looks perfectly OK to me, the alternative would be to loop on the options array with a forEach, but this approach looks better.

stivlo
  • 83,644
  • 31
  • 142
  • 199