Decoupling Java from HTML [SPR-12089]

[spring-projects-issues]

Andrew Luhring opened SPR-12089 and commented

1. Problem:
   Spring's view technologies do not offer a method to only access the lowest level of front-end data.

<form:form modelAttribute="searchCriteria" action="${hotelsUrl}" method="get" cssClass="inline">
    <span class="errors span-18">
        <form:errors path="*"/>
    </span>
    <fieldset>
        <div class="span-8">
            <label for="searchString">SeaString:</label>
            <form:input id="searchString" path="searchString"/>
        </div>
    </fieldset>

The problem is that most of that is unnecessary. In reality the only information the front end needs is:

"form" : {
    "name" : "searchCriteria"
  , "action" : "hotelsUrl"
  , "method": "get"
  , "errors" : [{
        "name" : (error cause)
     ,  "line" : (line number)
     ,  "trace": (stack trace)
     } , {
         (etc)
     }]
  ,  "inputs" : [{
       "name" : "search-string"
     , "type" : "text"
     } , {
       "name" : "other-input"
     , "type" : "number"
     } , { 
       "name" : "another-input"
     , "type" : "color"
     }]
}

By giving us data as a JSON or XML object, you decouple the data requirements of the requests from the implementation of the html.

For instance, this:

<label for="searchString">SeaString:</label>
<form:input id="searchString" path="searchString"/>

will output this:

<label for="searchString">SeaString:</label>
<input type="text" id="searchString" name="searchString" />

so what is a Front-End dev supposed to do if they disagree with that markup for that implementation? What if they want the markup, in this case, to be:

  <label><span class="accessibility-text">SeaString</span>
    <input 
       type="search" 
       min="3" 
       maxlength="30"
       placeholder="SeaString"
       autocomplete="on"
       required
       autofocus
    />
  </label>

Most of that can actually be done with jsp (or the other templating languages), EXCEPT this part:

<label>
  <input />
</label>

That seems like not a big deal, and it isn't if it were just that one case, but if you take this problem and do it for every templating element, it becomes a serious problem-- and that's assuming the Front-End isn't using any of the new frameworks like Backbone, Angular or Ember. If they ARE, they would be forced to mix JSP or worse Java, with their JavaScript.

So, please consider a shift in how spring implements the bridge between the front and back ends. The front end is growing more complicated by the day and back-end developers shouldn't have to think about whether they should template something as a section, article, main or aside element.

We collaborate through data, but lets keep our concerns separate.

---

Reference URL: http://spring.io/understanding/view-templates

0 votes, 6 watchers

[spring-projects-issues]

Juergen Hoeller commented

In your argument above, it seems that you're very focused on Spring's form tag library which happens to be a completely optional offering... Spring also comes with a JSP tag library for pure data binding (http://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring.tld.html), has support for JSP 2.0 EL and JSTL, etc.

So I'm not sure what you would like to see here: A different style of data access for JSPs? Specific tags that are even more minimal in their form input rendering that Spring's form tag library? If you do care about data binding in JSPs and have a concrete proposal here, feel free to sketch it or to submit a pull request with a prototype for it.

That said, please note that our JSP support is generally considered 'mature' and not actively being worked on. In Spring MVC, we rather focus on REST-style endpoints which deliver JSON and co to rich frontends these days... with JSP not playing much of a role anymore. This might be closer to the model that you have in mind anyway?

Juergen

[spring-projects-issues]

Brian Clozel commented

Spring guides show a wide variety of examples, including a Backbone.js application.

[spring-projects-issues]

Rossen Stoyanchev commented

As Juergen pointed out JSP is just one option. There are others like FreeMarker, Velocity, Thymeleaf, JMustache that don't allow any Java code in the templates. In 4.1 we are also adding support for Groovy Markup templating (see #16411) which may be of interest with its focus on minimal, don't-repeat-yourself style markup. Also Brian pointed out an example with client-side HTML templates.

Given that Spring MVC can be integrated with any view templating technology, is there a view technology (Java-based or not) along the lines of what you have in mind? Or at least an example?