Using array syntax generates invalid id using freemarker [SPR-8732]

[spring-projects-issues]

Przemek Ch opened SPR-8732 and commented

Method

protected String autogenerateId() throws JspException {
     return StringUtils.deleteAny(getName(), "[]");
}

form AbstractDataBoundFormElementTag class doesn't work with freemarker.

Example

<@spring.formInput path="lead.additionalSalesList[1].saleResult.policyId" attributes='class="policyId_1"'/>

generates

<input id="additionalSalesList[1].saleResult.policyId" class="policyId_0" type="text" value="" name="additionalSalesList[1].saleResult.policyId">

According to https://jira.springsource.org/browse/SPR-2380 the code above should generate id="additionalSalesList1.saleResult.policyId"

[] in ID is not a valid HTML so libraries like jQuery cant handle such elements

Tricks like this $(":input[name='additionalSalesList[1]\\.saleResult\\.policyId']") are needed now to select such items using jQuery.

---

Affects: 3.0.6

Issue Links:

• Using array syntax generates invalid id in freemarker [SPR-7710] #12366 Using array syntax generates invalid id in freemarker ("duplicates")
• Binding in Velocity templates using EL accessors ([, ]) for collections produces non xhtml strict compliant output [SPR-5172] #9845 Binding in Velocity templates using EL accessors ([, ]) for collections produces non xhtml strict compliant output

Referenced from: commits ba03d5b, e7e74c8, a9f4206

2 votes, 5 watchers

[spring-projects-issues]

Stevo Slavić commented

Created pull request which fixes this issue

[spring-projects-issues]

Rossen Stoyanchev commented

Pull request merged.

[spring-projects-issues]

Stevo Slavić commented

Issue #12366 duplicates this issue.

[spring-projects-issues]

Mike McEwan commented

Hi,

I have just decided to upgrade to Spring 3.2 and have been 'hit' by this change. I understand why the change has been made, but I wonder if the following code for formCheckbox was taken into account (from spring.ftl):

<#macro formCheckbox path attributes="">
  <@bind path />
  <#assign id="${status.expression?replace('[','')?replace(']','')}">
  <#assign isSelected = status.value?? && status.value?string=="true">
  <input type="hidden" name="_${id}" value="on"/>
  <input type="checkbox" id="${id}" name="${id}"<#if isSelected> checked="checked"</#if> ${attributes}/>
</#macro>

Note: The 'name' attribute of both the input fields is derived from the 'id'. This results in invalid property paths being submitted back to the server. Aside from the fact that in one of the input fields, the 'name' and 'id' fields are identical (is that allowed?), was/is it intentional that the 'name' attribute is derived from the 'id' - none of the other form elements in spring.ftl appear to do this?

Also, how is the removing of square brackets supposed to work with 2 dimensional arrays, lists of lists, lists of maps etc.? If I have a property path: table[${row}][${column}], and it is resolved to table[1][0] for the first column of the second row, and that is transformed to 'table10', isn't there a danger of this clashing with the id generated by a path of table[10]?

[spring-projects-issues]

Rossen Stoyanchev commented

Good questions. Stevo Slavić, any thoughts? Perhaps the change should be applied to ids only and not to names? To make sure the name can have two dimensional arrays or lists of maps.

[spring-projects-issues]

Stevo Slavić commented

Thanks Mike McEwan for spotting this regression. I've fixed formCheckbox macro so input names are again from status.expression, instead of computed id.
Rossen Stoyanchev please have a look at new pull request with this fix.

Regarding id collisions, if I'm not mistaken, they cannot or are at least highly unlikely to happen, and even if they would happen there is easy workaround in changing one of the command/model property/element name. Spring FreeMarker form macros don't do anything special, they auto-generate IDs consistently using same logic as Spring JSP form tags by just removing square brackets from path expression so if issue exists, it's present in Spring form JSP tags as well. I can imagine that changing id generation logic across all supported view technologies would break backward compatibility.
Mike McEwan, if you can think of a valid one, feel free to create a reproduction test case and open a new ticket for id collisions.

[spring-projects-issues]

Rossen Stoyanchev commented

Stevo Slavić, thanks for the quick turnaround.