Allow Indexed Collections as Form Commands [SPR-3450]

[spring-projects-issues]

Stephen Todd opened SPR-3450 and commented

Spring's current code makes it difficult to use java collections as a command in command controllers. Specifically, referencing elements in the collection is prevented. Currently, elements in an collection are references using []. Support needs to be added to allw paths to start with [index/key] as in "[1].property".

The application for this is probably rare, which is probably why it hasn't been brought up before (at least I couldn't find an similarly reported issues). I use the functionality for executing multiple of the same commands. I currently have a form that has multiple objects that can be selected. If the user clicks "Delete" with multiple objects selected, I have an array of id's that get passed to a delete form. This form creates a delete command for each object specified. Details for the way the objects are deleted are stored in an object, which is put in to a list. When the user submits the form, each command is executed in succession (the list is actually passed to the business layer and executed in a single transaction).

The current work around is to create a subclass of the java collection you want and make a getter that returns this. Then you can reference the array as (using a getter getSelf()) "self[1].property". Although this method works, a method that doesn't require this simple extension would be preferable.

---

Affects: 2.0.4

[spring-projects-issues]

Jörg Heinicke commented

This is a duplicate of #6751.

[spring-projects-issues]

Rossen Stoyanchev commented

This issue has been resolved through a selective bulk update, as part of a larger effort to better manage unresolved issues. To qualify for the update, the issue was either created before Spring 3.0 or affects a version older than Spring 3.0 and is not a bug.

There is a good chance the request was made obsolete, or at least partly outdated, by changes in later versions of Spring including deprecations. It is also possible it didn't get enough traction or we didn't have enough time to address it. One way or another, we didn't get to it.

If you believe the issue, or some aspects of it, are still relevant and worth pursuing at present you may re-open this issue or create a new one with a more up-to-date description.

We thank you for your contributions and encourage you to become familiar with the current process of managing Spring Framework JIRA issues that has been in use for over a year.