[2.2.2-java] duplicated list entries view for Lists. @repeat helper is wrong #2499
Conversation
|
The bug is related with the @repeat helper, modified for the play 2.2.2. Whatever was added there seems to have something wrong. With the previous @repeat helper it worked. Could you (@jroper) please, test what I explain in the main post, check it and correct it? |
Fixes playframework#2499 The actual bug was that the the Java Field.indexes implementation was not returning distinct indexes when the form had no value associated with it (eg, if it failed validation), so if a field that was repeated had multiple sub fields, the repeat hepler would render it once for every sub field. This only just exposed itself because the old repeat helper simply rendered as many fields as the maximum index. The new one however renders fields equivalent to what indexes exist in the form.
|
Fixed. See the attached commit for an explanation of the bug. We'll fix this in 2.2.3. As a work around in the meantime, you can use this implementation of the repeat helper: object repeat2 {
def apply(field: play.api.data.Field, min: Int = 1)(fieldRenderer: play.api.data.Field => Html): Seq[Html] = {
val indexes = field.indexes.distinct.sorted match {
case Nil => 0 until min
case complete if complete.size >= min => complete
case partial =>
// We don't have enough elements, append indexes starting from the largest
val start = partial.max + 1
val needed = min - partial.size
partial ++ (start until (start + needed))
}
indexes.map(i => fieldRenderer(field("[" + i + "]")))
}
} |
|
Thanks for the fast solution. But I'm afraid now there's a problem with the workaround you provided, ordering the result. Using the same forms sample do as follows:
You will see how in the response the profile order is exchanged and lost. (I am experiencing those problems in my own project, forms is just an easy sample how to explain the wrong behavior) |
|
That fix LGTM. @jroper, would you like me to merge it? |
|
Ok, seems like we need some more tests (though it's very hard to know if your tests are hitting hashmap ordering issues). |
Fixes playframework#2499 The actual bug was that the the Java Field.indexes implementation was not returning distinct indexes when the form had no value associated with it (eg, if it failed validation), so if a field that was repeated had multiple sub fields, the repeat hepler would render it once for every sub field. Additionally, in that case, the ordering of the indexes was made random by virtue of being calculated fdrom the keys of a HashMap, where but the indexes should be returned in order. This only just exposed itself because the old repeat helper simply rendered as many fields as the maximum index. The new one however renders fields equivalent to what indexes exist in the form. New tests test both that only one of each index appears, and that indexes are always returned in order.
|
I've added new tests/modified existing tests to assert the ordering of the repeated fields, and fixed the bug. @richdougherty review again then merge? This should also be merged to 2.2.x since it's a regression. |
|
@umbreak Actually I didn't noticed that you were reporting the issue with the work around, I thought you said the issue was in my fix (the same issue occurred in the fix, and that issue is now fixed). I've updated the work around above to fix it (very easy, simply called |
|
I'll merge today if I can get master to build properly. |
|
Master is blue. |
|
@richdougherty looks like it's building properly now. shows green for me |
[2.2.2-java] duplicated list entries view for Lists. @repeat helper is wrong
Fixes playframework#2499 The actual bug was that the the Java Field.indexes implementation was not returning distinct indexes when the form had no value associated with it (eg, if it failed validation), so if a field that was repeated had multiple sub fields, the repeat hepler would render it once for every sub field. Additionally, in that case, the ordering of the indexes was made random by virtue of being calculated fdrom the keys of a HashMap, where but the indexes should be returned in order. This only just exposed itself because the old repeat helper simply rendered as many fields as the maximum index. The new one however renders fields equivalent to what indexes exist in the form. New tests test both that only one of each index appears, and that indexes are always returned in order.
With play 2.2.2 and the project samples/java/forms, in the route http://localhost:9000/contacts if you try to click in INSERT without filling any field, the view is refreshed and it shows the corresponding "Required field" error with more PROFILES than the ones created.
The same sample run using play-2.2.1 do not have this problem.
I don't know if the issue is in the controller side with parsing List of objects, or in the view side, with the Form object.