Predictable property order for both grid & form

[mstahv]

setColumns & setVisibleProperties calls now become more like optional configuration than must have. Removes a ton of nasty looking non-type configuration code.

BTW. Now that property order is "correct", in many cases an inverted approach for visible column/property configuration would be often better, something like setHiddenColumns/Properties 🤔

And yeah, next step would be to replace Binder with FormBinder from Viritin to make crossfield validation work properly 🤓

[mstahv]

Added property hiding, partly to VGrid, so no release for transitive dependency yet. Will cut a version still soon...

[mstahv]

Dependency now syncing to Maven Central

[mstahv]

Added also fixes to #125 & #127, essentially added a support for wider set of basic data types

[alejandro-du]

@mstahv - Thanks for the contribution. Is there any way to implement this so that no additional dependencies are added?

[mstahv]

Sure, just copy all the code from dependencies 🤪 Jackson (that is mostly used here) is a dependency coming in via Vaadin, that isn't going anywhere. VGrid from Viritin is essentially the Vaadin Grid, but with proper property handling (and some other very handy features). Hiding its more specific type (at least by default), would be nice, but then the column hiding would need to be moved to the top level.

On my list would be to add buillt in support for enums, lists/sets of basic data types & simple objects, Java recorods and doing some UX improvements. For those Viritin would need to be cloned in completely 🤷‍♂️

BTW. Some obsolete code was left in the example. Removed.

[mstahv]

Added some additional cleanup (thanks to Vaadin improvements) and removed H2 config so that the demo app starts without additional tricks. As a DB fellow you ought to update that to use TestContainers & MariaDB 🤓

[alejandro-du]

Yeah, I wasn't clear or precise. I was referring to the dependency added to the pom.xml file (viritin). Is it possible to implement "predictable property order" without it? My policy with this add-on is not to include add-on dependencies that are not Vaadin-official. This is one of the reasons this add-on is successful—it uses "plain Vaadin" with no additional dependencies (that are not provided-scoped).

Thanks a lot for the additional cleanup.