3.x.x release notes
3.1.0.RELEASE
-
if an
EntityAssociation
has a customEntityFactory
attribute, that factory will be used for both new instance and DTO creation-
previously it was only used for new instance creation
-
-
EntityModule now uses
evo-inflector
to auto-generate plural forms, this should yield better results in English -
the
String
formats of auditable properties can now be customized using global message codes:-
Auditable.createdDate
-
Auditable.created
-
Auditable.lastModifiedDate
-
Auditable.lastModified
-
-
several minor issues with EQL filtering have been fixed
-
EntityQuery
condition translation is now done recursively as long as the result is modified -
a
CollectionEntityQueryExecutor
implementation has been added that can be used to query a collection of objects if there is anEntityPropertyRegistry
which provides the property metadata of the collection members
3.0.1.RELEASE
-
the module dependencies for EntityModule have been optimized for re-use
-
as a result EntityModule no longer transitively pulls in BootstrapUiModule or AdminWebModule
-
when used without BootstrapUiModule, no default
ViewElement
rendering infrastructure will be available -
when used with BootstrapUiModule but without AdminWebModule, the default views for an entity will never get created and view support (
EntityViewFactory
) will be disabled
-
-
added support for
LocalDate
,LocalTime
andLocalDateTime
to be rendered usingDateTimeFormElement
-
it is now possible to configure default view element modes (eg. control or readonly rendering) on an
EntityConfiguration
-
these will be used in all cases where no specific configuration has been configured on property level
-
-
configuration & view builders support
AttributeRegistrar
for registering or removing attributes-
using
AttributeRegistrar
is useful if you want to use the owner of the attribute collection (eg. theEntityConfiguration
) -
common default registrars can be found in the
EntityAttributeRegistrars
utility class
-
-
entity views can now have a collection of configuration attributes
-
attributes can be used to influence or extend default behaviour, new attributes are available for permission checking and admin menu rendering
-
during view rendering attributes are accessible (and can be modified) using
EntityViewRequest.getConfigurationAttributes()
-
-
improvements to view configuration
-
EntityViewFactoryAttributes.ADMIN_MENU
attribute can be used to specify if a view should have an admin menu item added -
EntityViewFactoryAttributes.ACCESS_VALIDATOR
attribute can be used to determine how access to the view should be validated
-
-
added an
ExtensionViewProcessorAdapter
base class for easily creating a view for a custom extension class (see how-to) -
added
EntityViewCustomizers
utility class providing some helpers for customizingEntityViewFactoryBuilder
in a chainable fashion -
EntityModule no longer creates its own
Validator
instance, theregisterForMvc
related settings have been removed-
the validator used by EntityModule is the default MVC validator
-
-
it’s now possible to define a different message code prefix for module entities using properties
-
you can now force the required status of a control by setting the
EntityAttributes.REQUIRED_PROPERTY
attribute totrue
orfalse
on anEntityPropertyDescriptor
-
message codes for form groups and fieldsets have been extended, apart from
[description]
, there is now also built-in support for[help]
and[tooltip]
-
this constitutes a minor breaking change in that
[description]
content is now always rendered above the control of a form group. Previously this could be different depending on the type of control inside the form group. -
see the section configuring form controls text for a full explanation of the new message codes
-
-
the behaviour of when controls are prefixed with
entity.
has been changed-
when using
EntityViewCommand
all property controls of the base entity will should be prefixed withentity.
in order to map on theEntityViewCommand.entity
values -
previously this was done always when an
EntityViewCommand
was found on theViewElementBuilderContext
-
in the new version this is only done if there is also an attribute
EntityPropertyControlNamePostProcessor.PREFIX_CONTROL_NAMES
explicitly set totrue
on the builder context-
the latter is done automatically by the
PropertyRenderingViewProcessor
when building the initial controls
-
-
though not intentionally breaking, this change can have side effects with controls no longer being prefixed, developers are encouraged to test the custom forms they have
-
-
new components for linking to entity views have been introduced
-
the old
EntityLinkBuilder
interface and attributes are deprecated, but should still work as before -
see the chapter on linking to entity views for an overview of the new components
-