7 ms·

>Part of it is a framework issue. Struts is horrible...absolutely, stunningly horrible. Your controller is an XML file (seriously). Freemarker (the main templat

• latch 14y ago
  My complaint isn't about client-side rendering. It's about _anything_ that involves getting in JSON or outputting JSON. It's essentially being able to easily bind json to objects on the way in, and being able to use respond_to and to_json on the way out.
  • fizx 14y ago
    You're stuck in 2007. People doing modern java use: @Path("/hello") @Produces(MediaType.APPLICATION_JSON) class HelloController { class Greeting { public Greeting(String name) { this.content = "Hello, " + name; } public final String content; } @GET public Greeting greet(@PathParam("name") String name) { return new Greeting(name); } } > curl http://localhost:8080/hello?name=me {"content": "Hello, me"}
    • latch 14y ago
      I'm not sure if you are being sarcastic, but you do realize that's a lot of code for something so simple, right? get '/hello/:name' do content_type :json {:content => "Hello, #{params[:name]}"}.to_json end
      • gizmogwai 14y ago
        I'm not sure if you are being sarcastic, but you do realize that your version is entirely static while the other one is ready for future evolutions? By changing a single line, the java version can also produce XML or text response. By changing two lines, it can also respond to POST requests. And that's just the top of the iceberg. Oh, and in the ends, it's way faster than Node, Ruby, Python and most of the dynamic languages.
        • Retric 14y ago
          That's a funny complaint when evaluating 4 lines of code one of which is end. Java makes the assumption that you need a lot of boilerplate code, so being able to make changes easily seems like a big deal. Other languages avoid that boilerplate and can make the changes just as easily for free.
          • thebluesky 14y ago
            Making changes to a complex system is a "big deal" in any language. Pretty (and compact) syntax doesn't help much, especially when the refactoring tools are weak.
        • latch 14y ago
          And when those changes are made, I can change my version to: response = {:content => "Hello, #{params[:name]}"} respond_to do |wants| wants.json { response.to_json } wants.xml { response.to_xml } end
          • fizx 14y ago
            I've been trying to ignore this particular flame-war, but your example is doing fundamentally less, because it's not binding objects to json (which was what you originally asked for). I actually cannot write your example easily in Sinatra/Ruby/etc, without making my object either a Hash or an ORM subclass, customizing serialization, or pulling in uncommon libraries. Here's your complete example, in reasonable Ruby. It's longer than the Java. class Greeting < Struct.new(:content) def content "Hello, #{super.content}" end def to_xml {:content => content}.to_xml end def to_json {:content => content}.to_json end end get '/hello' do response = { :content => Greeting.new(params[:name]) } respond_to do |wants| wants.json { response.to_json } wants.xml { response.to_xml } end end If I create an imaginary library that does exactly what we'd want here, it'd look like the following. It's marginally shorter than the java, but hard to argue anything about it being fundamentally better. class Greeting include JsonObject field :content def content "Hello, #{@content}" end end get '/hello' do response = { :content => Greeting.new(params[:name]) } respond_to do |wants| wants.json { response.to_json } wants.xml { response.to_xml } end end
    • swah 14y ago
      Its fine code once the design its settled, but while you're changing the schema, the backend java code and the frontend javascript, having to change all those classes gets tedious.