f-lopes / spring-mvc-test-utils

Test library aimed to ease Spring MVC form validation tests. Easily post an entire form to a given url.
MIT License
19 stars 8 forks source link

Support multidimensional arrays and maps #5

Open poikilotherm opened 6 years ago

poikilotherm commented 6 years ago

Dear @f-lopes,

the addition of support for Map types in #3 is great! In future forms, I will need to test with multidimensional arrays and maps (Array of Arrays, Map of Maps or even more dimensions).

Would you agree that adding support for them would respond to a common pattern of data usage? (At least I know this concept is heavily used within the PHP/Python/Perl world...)

Cheers, Poikilotherm

poikilotherm commented 6 years ago

@f-lopes would you welcome a PR for this? I actually need this... :wink:

f-lopes commented 6 years ago

Dear @poikilotherm,

Of course 😃, I will commit my changes soon (https://github.com/f-lopes/spring-mvc-test-utils/issues/4) to make sure you work on the latest codebase.

poikilotherm commented 6 years ago

Hey @f-lopes

I started to work on this in https://github.com/poikilotherm/spring-mvc-test-utils/tree/support_mapOmap.

Unfortanetly, I can't get the Smoke Test fullTest() to work, because the three dimensional map seems not to be supported. While using a two dim map, this is no problem at all... :thinking:

I tried to use such three dimensional maps in real forms and that was no problem at all... I just don't get it - maybe you have an idea?

f-lopes commented 6 years ago

Hi @poikilotherm,

I saw your work on the fork. Multi-dimensional Map parameters need to be separated by dots "." to instantiate nested properties. The smoke test is passing when adding the following parameter: mmData[orgUnit].[employee].[firstName]=John

Could you first write unit tests to validate the three-dimensional map mapping to HTTP parameters?

Thanks.

poikilotherm commented 6 years ago

Hi @f-lopes,

I already wrote that unit test first... ;-)

Actually I think we cannot use more than two dimensions. After testing this again with some example code, I can use maps with more than 2 dimensions within templates (SpEL seems to be ok with that when used in Thymeleaf), but when I try to submit the data, the binding fails with the exact same error.

I was not able to find any documentation on this and after digging through the Spring Framework source code, I was even more confused of the black magic that happens in the data binding background. Even in the Spring JIRA issues I was not able to find anything... Do you know some of the devs, so we might ask them directly? Not sure if they would react here on GitHub if we mention them...

Using the "dotted" notation you mentioned above might get things to work, but this is no good, as Thymeleaf etc are not using this format (they use the name[key1][key2][...] notation).

So maybe lets stick with 2 dimensions for now? (Will have to redesign my models, but well... things happen...)

f-lopes commented 6 years ago

Hi @poikilotherm,

Sorry, I didn't find the unit test at first ;)

Of course, your solution may be to use a List to model your data. Is the problem related to the "auto-growing/instantiation" of nested Map properties. These discussions might help:

Unfortunately, I don't know any developer from the Spring team.

For your information, I will open a pull request to give you the possibility to discuss the next version (2.0.0) which will rely on Spring's TypeConverter implementation.

poikilotherm commented 6 years ago

Thank you for the links @f-lopes. Unfortanetly I already had a look at those while digging through Google and they didn't enlighten me regarding this specific problem. The upstream bug report is closed as fixed, too...

As a consequence, I opened a new issue: https://jira.spring.io/browse/SPR-16745

Let's keep our fingers crossed some of the devs find the time to respond.

f-lopes commented 6 years ago

Thanks for the issue.

I've created a pull-request for the next release (https://github.com/f-lopes/spring-mvc-test-utils/pull/7). Feel free to add your suggestions.

Thanks.