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
I'm planning a major revamp of how exports work and features.
Exports (larger explanation here) allow Property names and values to be exported in some way. Currently the only implementation exports the Properties contained in a class to be exported to System.Properties. Its pretty limited, but does allow legacy code expecting to read System.Properties to benefit from AndHow.
The new export system will improve on that functionality in a few ways. First, 'manual' exports will be added. With a manual export, a class annotated with @ManualExportAllowed can be exported in code and used however needed. Frameworks like Hibernate, which can accept configuration from a Map of values, could be configured this way. Usage would look something like this:
Another form of that method might take a lambda to let the caller build whatever data structure they want.
Other improvements planned will be:
Support for nested inner classes
If a class is annotated for automatic export or manual export, it seems nature that any contained inner classes with Properties should be exported as well.
Support to block specific inner classes from export
Annotations like @ManualExportNotAllowed or @AutomaticExportNotAllowed can be used to block the behavior above.
General cleanup and better testing of export code
The existing export code is bundled deep in procedural logic. This code will be moved out to separate classes where it can be unit tested more easily.
The new features for the automatic exports may require new annotations, however, the old @GroupExport and its current behavior will be kept, though it may be marked as deprecated. Removal will be a few major releases down the path because there are applications using this annotation.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I'm planning a major revamp of how exports work and features.
Exports (larger explanation here) allow Property names and values to be exported in some way. Currently the only implementation exports the Properties contained in a class to be exported to System.Properties. Its pretty limited, but does allow legacy code expecting to read System.Properties to benefit from AndHow.
The new export system will improve on that functionality in a few ways. First, 'manual' exports will be added. With a manual export, a class annotated with
@ManualExportAllowed
can be exported in code and used however needed. Frameworks like Hibernate, which can accept configuration from aMap
of values, could be configured this way. Usage would look something like this:Another form of that method might take a lambda to let the caller build whatever data structure they want.
Other improvements planned will be:
If a class is annotated for automatic export or manual export, it seems nature that any contained inner classes with Properties should be exported as well.
Annotations like
@ManualExportNotAllowed
or@AutomaticExportNotAllowed
can be used to block the behavior above.The existing export code is bundled deep in procedural logic. This code will be moved out to separate classes where it can be unit tested more easily.
@GroupExport
and its current behavior will be kept, though it may be marked as deprecated. Removal will be a few major releases down the path because there are applications using this annotation.Beta Was this translation helpful? Give feedback.
All reactions