Skip to content

Generic Filter: programmatic API is inconvenient and unsafe #5083#5090

Draft
fractal3000 wants to merge 5 commits intomasterfrom
feature/5083-Generic-Filter-programmatic-API-is-inconvenient-and-unsafe
Draft

Generic Filter: programmatic API is inconvenient and unsafe #5083#5090
fractal3000 wants to merge 5 commits intomasterfrom
feature/5083-Generic-Filter-programmatic-API-is-inconvenient-and-unsafe

Conversation

@fractal3000
Copy link
Copy Markdown
Contributor

fractal3000 and others added 5 commits February 20, 2026 23:38
- Add MutableConfiguration interface extending Configuration; RunTimeConfiguration
  now implements it, giving compile-time safety against calling mutating methods
  on DesignTimeConfiguration
- Fix RunTimeConfiguration: subscribe to FilterComponentsChangeEvent from the root
  component so that components added after construction are automatically marked as
  modified (remove buttons appear without a manual setModified call)
- Add FilterComponentBuilder with PropertyFilterBuilder, JpqlFilterBuilder and
  GroupFilterBuilder: encapsulates mandatory init steps (setConditionModificationDelegated,
  setDataLoader, correct property→operation→value ordering)
- Add DesignTimeConfigurationBuilder and RunTimeConfigurationBuilder: fluent API for
  creating and registering configurations with automatic setFilterComponentDefaultValue
- Add GenericFilter.refreshCurrentConfiguration(), addAndSetCurrentConfiguration(),
  componentBuilder(), configurationBuilder(), runtimeConfigurationBuilder()

All changes are purely additive; no existing classes or methods are modified.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ilders

- Add GenericFilterBuilderApiTest: 24 narrow integration tests (Spock/Spring)
  that serve as executable documentation for FilterComponentBuilder,
  DesignTimeConfigurationBuilder, RunTimeConfigurationBuilder,
  RunTimeConfiguration auto-tracking, and the GenericFilter helper methods
  (addAndSetCurrentConfiguration, refreshCurrentConfiguration,
  setCurrentConfiguration silent-ignore behaviour).
  Class-level Javadoc explains why isolated unit tests are not practical
  for these classes (Spring/Vaadin bootstrapping requirements).

- Guard setValue() in DesignTimeConfigurationBuilder and
  RunTimeConfigurationBuilder with a best-effort try-catch: the component's
  value may not be fully initialised when no DataLoader is assigned (tests,
  lazy initialisation). The configuration default value is always persisted
  via setFilterComponentDefaultValue regardless of whether setValue succeeds.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
… 3.0)

Six mutating methods that throw UnsupportedOperationException when called on
DesignTimeConfiguration are now marked @deprecated(since = "2.8", forRemoval = true)
in the Configuration interface:
  setName, setRootLogicalFilterComponent, setModified, setFilterComponentModified,
  resetFilterComponentDefaultValue, resetAllDefaultValues.

Migration path documented in the Configuration class Javadoc:
  - Declare variables/parameters as MutableConfiguration (implemented only by
    RunTimeConfiguration) to get compile-time safety and no deprecation warning.
  - Use (config instanceof MutableConfiguration) for dynamic checks.

MutableConfiguration re-declares all six methods without @deprecated, so callers
that already use MutableConfiguration or RunTimeConfiguration see no new warnings.

DesignTimeConfiguration gets a brief note explaining the connection to the
deprecation and the 3.0 plan.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Add @internal to classes and sub-packages that are framework
implementation details and should not be used by application developers:

- GenericFilterActionsSupport
- FilterUtils (class level; methods already had it)
- FilterConfigurationPersistence
- FilterComponents (registration)
- inspector/ package (new package-info.java)
- model/ package (new package-info.java)

FilterComponentRegistration and FilterComponentRegistrationBuilder
remain public: they are the intentional SPI for add-on developers
registering custom filter component types.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@fractal3000 fractal3000 marked this pull request as draft February 23, 2026 21:46
@fractal3000 fractal3000 linked an issue Feb 23, 2026 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Generic Filter: programmatic API is inconvenient and unsafe

1 participant