Status
This issue originally listed four improvements to GenericFilter's programmatic API.
#5351 (PR #5363) delivered two of them and addressed a third differently. This issue now
tracks the remaining work.
| # |
Improvement |
Status |
| 1 |
MutableConfiguration interface — fix Configuration LSP violation |
❌ Remaining |
| 2 |
Atomic "register + activate" |
⚠️ Resolved differently (see below) |
| 3 |
Stable public refreshCurrentConfiguration() |
✅ Done in #5351 |
| 4 |
protectedFromUserDeletion flag |
✅ Done in #5351 (with a deviation, see note) |
Remaining scope: split Configuration into a read-only interface + MutableConfiguration
Problem (unchanged)
Configuration declares mutating methods — setName, setRootLogicalFilterComponent,
setModified, setFilterComponentModified, setFilterComponentDefaultValue,
resetFilterComponentDefaultValue, resetAllDefaultValues — that DesignTimeConfiguration
cannot fulfil: it throws UnsupportedOperationException at runtime. There is no compile-time
signal that these methods are unsafe to call on a design-time configuration (LSP violation).
Expected behaviour
Configuration becomes read-only (identity, getters, getQueryCondition, read-only flags).- A new
MutableConfiguration extends Configuration exposes the mutating methods.
RunTimeConfiguration implements MutableConfiguration;
DesignTimeConfiguration implements Configuration — no more UnsupportedOperationException
overrides.- APIs that mutate a configuration accept/return
MutableConfiguration, so passing a
design-time configuration into a mutating context becomes a compile error, not a
runtime exception.
Compatibility note
Configuration is public API. Moving the mutators to MutableConfiguration is a breaking
change for any caller that mutates a configuration through the Configuration type. The
migration must be completed within the same change (callers updated; no mutators left
deprecated-but-still-declared on Configuration).
Notes on what was already delivered
Point 4 — protectedFromUserDeletion (done, with deviations):
The flag currently lives on the concrete RunTimeConfiguration
(isProtectedFromUserDeletion() / setProtectedFromUserDeletion()) — once
MutableConfiguration exists it should move there. By design it only hides the Remove
action in the filter toolbar (GenericFilterRemoveAction#isApplicable); programmatic
removeConfiguration() still removes the configuration (it is used internally, e.g. by the
rename flow). This intentionally deviates from the original wording ("prevents
removeConfiguration()").
Point 2 — atomic register + activate (resolved differently):
Instead of a dedicated addAndSetCurrentConfiguration() method, the wrong-order / silent
no-op problem is mitigated by setCurrentConfiguration() now logging a warning when the
configuration is not registered. The atomic method was prototyped during #5351 and
intentionally dropped to avoid growing the API surface. No further action planned unless a
concrete need arises.
Status
This issue originally listed four improvements to
GenericFilter's programmatic API.#5351 (PR #5363) delivered two of them and addressed a third differently. This issue now
tracks the remaining work.
MutableConfigurationinterface — fixConfigurationLSP violationrefreshCurrentConfiguration()protectedFromUserDeletionflagRemaining scope: split
Configurationinto a read-only interface +MutableConfigurationProblem (unchanged)
Configurationdeclares mutating methods —setName,setRootLogicalFilterComponent,setModified,setFilterComponentModified,setFilterComponentDefaultValue,resetFilterComponentDefaultValue,resetAllDefaultValues— thatDesignTimeConfigurationcannot fulfil: it throws
UnsupportedOperationExceptionat runtime. There is no compile-timesignal that these methods are unsafe to call on a design-time configuration (LSP violation).
Expected behaviour
Configurationbecomes read-only (identity, getters,getQueryCondition, read-only flags).MutableConfiguration extends Configurationexposes the mutating methods.RunTimeConfiguration implements MutableConfiguration;DesignTimeConfiguration implements Configuration— no moreUnsupportedOperationExceptionoverrides.
MutableConfiguration, so passing adesign-time configuration into a mutating context becomes a compile error, not a
runtime exception.
Compatibility note
Configurationis public API. Moving the mutators toMutableConfigurationis a breakingchange for any caller that mutates a configuration through the
Configurationtype. Themigration must be completed within the same change (callers updated; no mutators left
deprecated-but-still-declared on
Configuration).Notes on what was already delivered
Point 4 —
protectedFromUserDeletion(done, with deviations):The flag currently lives on the concrete
RunTimeConfiguration(
isProtectedFromUserDeletion()/setProtectedFromUserDeletion()) — onceMutableConfigurationexists it should move there. By design it only hides the Removeaction in the filter toolbar (
GenericFilterRemoveAction#isApplicable); programmaticremoveConfiguration()still removes the configuration (it is used internally, e.g. by therename flow). This intentionally deviates from the original wording ("prevents
removeConfiguration()").Point 2 — atomic register + activate (resolved differently):
Instead of a dedicated
addAndSetCurrentConfiguration()method, the wrong-order / silentno-op problem is mitigated by
setCurrentConfiguration()now logging a warning when theconfiguration is not registered. The atomic method was prototyped during #5351 and
intentionally dropped to avoid growing the API surface. No further action planned unless a
concrete need arises.