3.x.x release notes

3.1.0.RELEASE

  • if an EntityAssociation has a custom EntityFactory 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 an EntityPropertyRegistry 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 and LocalDateTime to be rendered using DateTimeFormElement

  • 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. the EntityConfiguration)

    • 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 customizing EntityViewFactoryBuilder in a chainable fashion

  • EntityModule no longer creates its own Validator instance, the registerForMvc 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 to true or false on an EntityPropertyDescriptor

  • 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 with entity. in order to map on the EntityViewCommand.entity values

    • previously this was done always when an EntityViewCommand was found on the ViewElementBuilderContext

    • in the new version this is only done if there is also an attribute EntityPropertyControlNamePostProcessor.PREFIX_CONTROL_NAMES explicitly set to true 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