Fix breaking FormsFX changes

[martinfrancois]

Since FormsFX 1.3.0, because of dlsc-software-consulting-gmbh/FormsFX#28 there is no longer a call to getFields(), which was replaced to a call to getElements() instead. Also, a concept of Elements was introduced, which Field now extends. The missing call caused a breaking change, since in our own implementation of a renderer, we used said call.

This fix is not ideal, since it casts the Elements we get from getElement() to a Field, which means if someone would want to define an Element, it would throw a ClassCastException. However, it is a good tradeoff, since we currently only support Field anyways and changing PreferencesFX to consistently use Element instead is a quite major refactoring, as almost all classes use Field in some form, especially including our custom renderers.

[dlemmermann]

But aren't those elements things like additional text for describing a field? I know that @aalmiray added some functionality for this in FormsFX. Was he planning on also using it in PreferencesFX?

[martinfrancois]

@dlemmermann could be, but in this case I would suggest to add the Element functionality at a later point to the API, also exposing Element instead of Field for Settings.

[aalmiray]

Indeed. Element is required in order to render additional content related to a Field. This is part of the possible enhancements that can be added to PreferencesFX.

[dlemmermann]

OK, but this has to be done in a later release then. For now PreferencesFX will only support Fields. I have asked the team to submit an enhancement ticket for the new features.