You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of FormsFX 1.3.0, introduced by dlsc-software-consulting-gmbh/FormsFX#28 a Field is now a subclass of Element. From PreferencesFX 2.1.0, the included dependency of FormsFX has been updated to 1.3.0, but still only Field is supported and not Element.
By using Field we are limited in terms of the features of FormsFX we and also the API user can use and thereby benefit from.
This change would involve replacing all occurences of Field with Element and to also expose Element instead of Field externally. Currently, a quick fix is in place (#39), which casts the Element objects to Fields. Going with Element internally instead of Field eliminates the need for a cast and opens up additional features which can then be used for custom controls and also to expose additional functionality with PreferencesFX.
Migrating to the new architecture of FormsFX makes sense, but since PreferencesFX makes heavy use of FormsFX, also using custom renderers and controls to change a lot of the behavior of FormsFX, this is not an easy task, while still preserving the original functionality as currently implemented by PreferencesFX.
The text was updated successfully, but these errors were encountered:
As of FormsFX 1.3.0, introduced by dlsc-software-consulting-gmbh/FormsFX#28 a
Field
is now a subclass ofElement
. From PreferencesFX 2.1.0, the included dependency of FormsFX has been updated to 1.3.0, but still onlyField
is supported and notElement
.By using
Field
we are limited in terms of the features of FormsFX we and also the API user can use and thereby benefit from.This change would involve replacing all occurences of
Field
withElement
and to also exposeElement
instead ofField
externally. Currently, a quick fix is in place (#39), which casts theElement
objects toField
s. Going withElement
internally instead ofField
eliminates the need for a cast and opens up additional features which can then be used for custom controls and also to expose additional functionality with PreferencesFX.Migrating to the new architecture of FormsFX makes sense, but since PreferencesFX makes heavy use of FormsFX, also using custom renderers and controls to change a lot of the behavior of FormsFX, this is not an easy task, while still preserving the original functionality as currently implemented by PreferencesFX.
The text was updated successfully, but these errors were encountered: