Contracts Reference

Flare exposes a set of small interfaces that opt a filter element, list driver, or helper object into specific behavior.

Most custom filter elements extend AbstractFilterElement and most custom list drivers extend AbstractListDriver. Those base classes already implement several contracts with no-op or default behavior, so you only need to override the contracts that matter for your type.

Contracts are grouped into three categories:

1. Filter Element Contracts

The element lifecycle interfaces live in HeimrichHannot\FlareBundle\Filter\Element\ and are covered in depth by the custom filter elements guide:

• FilterElementInterface: The core contract every element implements — buildForm() adds the frontend form controls, buildFilter() translates config and submitted data into filter-type calls.
• IntrinsicContract (Contract\FilterElement\): Marks an element as always intrinsic via isOnlyIntrinsic() — it never renders form controls, and the backend forces the intrinsic flag on its filter records.

2. List Driver Contracts

These live in HeimrichHannot\FlareBundle\Contract\ListDriver\:

• BuildQueryContract: Register joins and customize the base SQL query.
• BuildListContract: Take part in the list build lifecycle — buildList(ListSpecBuilder) adds filters or config overrides before the ListSpec is built (see the custom list drivers guide).
• DataContainerContract: Resolve the list record's dc value during backend editing.

3. General Contracts

These apply to filter elements and list drivers alike:

• OptionsContract: Declare a canonical config schema with Symfony's OptionsResolver (configureOptions()).
• TransformerContract: Declare per-source transformers translating a stored source (e.g. a DCA model) into canonical config values (configureTransformers()).
• DcaContract: Assemble the type's backend palette and DCA field tweaks at runtime.
• IsSupportedContract: Hide unsupported services from bundle integrations that check availability.