3.x.x release notes

this allows consumers to customize the entire form group for a filter control, separately from the control itself

the default implementation is a CollectionEntityQueryExecutor using the repository to fetch all items

previously only JpaSpecificationExecutor and QueryDslPredicateExecutor would register an EntityQueryExecutor

this can be especially helpful when building a UI for entities spanning multiple datasources or from webservice APIs

this removes the need to provide a custom AssociatedEntityQueryExecutor for manually defined associations

general rule is that any custom type without readable/writable properties will yield a textbox control

fixed bug where a NullPointerException was thrown if an invalid EQL expression was entered in an advanced filter

Java 8 time types are now supported for now() and today() functions

custom textbox types (eg email) are now supported for basic filtering

its value should be the actual enctype that should be used for submitting the form of a form view, eg FormViewElement.ENC_MULTIPART

this is especially useful to change the form enctype based on the presence of property descriptors (for example a file property)

the attribute on a EntityViewFactory will take precedence, property descriptors will only be inspected if it is missing

a fieldset can now be rendered either as a HTML FieldsetFormElement or using a custom template

a custom template can be configured on a property using the ViewElementFieldset.TEMPLATE attribute

several default templates have been provided with default styling for common form layouts in Admin Web

if no property selector is specified, a fieldset property will select all child properties as its members

this can be used to hide items from a list view if the user does not have the correct permissions

it’s possible to configure an entity to link to the detail view instead of the update view by default

see the customize link to delete view guide to revert to the previous behaviour.

the sub-menu is only rendered if there are at least 2 menu items

this allows an additional level of menu items for managing embedded associations

each property is now backed by an EntityPropertyController which can be used to set behaviour (data fetching, writing) on a single property level

fixed some issues with using UUID or other custom types as id for entities

added default control support for ZonedDateTime and Duration

added EQL support for CONTAINS NULL as an alternative to IS EMPTY

improved EQL support for negative operands: NOT CONTAINS (1,2) now expands to NOT CONTAINS 1 AND NOT CONTAINS 2

previously it was only used for new instance creation

Auditable.createdDate

Auditable.created

Auditable.lastModifiedDate

Auditable.lastModified

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

these will be used in all cases where no specific configuration has been configured on property level

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

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()

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

the validator used by EntityModule is the default MVC validator

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

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

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

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