feat(forms): add an interface for embeddable question types - #25065
Open
UncleTomsCabi wants to merge 1 commit into
Open
feat(forms): add an interface for embeddable question types#25065UncleTomsCabi wants to merge 1 commit into
UncleTomsCabi wants to merge 1 commit into
Conversation
## Summary Introduce a dedicated interface for question types that can be rendered inside another question type. This adds a standard contract that allows composite question types (such as table questions) to reuse administration and end-user rendering provided by other question types without relying on plugin-specific implementations. The interface currently defines two responsibilities: - rendering administration controls with a supplied input prefix; - rendering end-user controls with a supplied input name. No existing question type is modified by this change. ## Motivation Currently there is no standard way for a question type to expose embeddable rendering. As a result, plugins must rely on runtime capability detection (`method_exists()`) or hard dependencies between plugins. Adding this interface provides a generic extension point that can be reused by any current or future question type. ## Backward compatibility This change is fully backward compatible. Existing question types continue working without modification. Only question types implementing the new interface expose the additional capability. ## Related - Fields PR: - Advanced Forms PR:
UncleTomsCabi
added a commit
to UncleTomsCabi/advancedforms
that referenced
this pull request
Aug 2, 2026
## Summary Add support for embeddable question types inside table question columns. Instead of knowing about specific plugins, the table question now delegates rendering to any question type implementing the new embeddable interface. ## What is implemented - support for embeddable question types; - dynamic column configuration loading; - embedded administration rendering; - embedded end-user rendering; - server-side rendering for dynamically added table rows; - validation and preparation of embedded question extra data. ## Why server-side row rendering? Originally, additional table rows were created entirely in JavaScript. This approach worked for built-in question types because their client-side configuration was sufficient to recreate the controls. With embeddable question types, this is no longer enough. Embedded question types are responsible for rendering and initializing their own controls, which may include server-generated markup, unique identifiers and initialization logic. To keep this responsibility inside each question type and avoid duplicating rendering logic in JavaScript, newly added rows are now rendered on demand by the server through a dedicated controller. The controller simply exposes the existing row rendering logic already used for the initial table rendering, ensuring that dynamically added rows behave exactly like the initially rendered ones. ## Motivation The table question previously only supported built-in question types. With this change, any question type implementing the embeddable interface can be used inside a table without introducing plugin-specific rendering logic into Advanced Forms. ## Backward compatibility Existing built-in question types continue to work exactly as before. Plugins that do not implement the embeddable interface are unaffected. ## Related Depends on: - GLPI Core PR: glpi-project/glpi#25065 Example implementation: - Fields PR: pluginsGLPI/fields#1235
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Introduce a dedicated interface for question types that can be rendered inside another question type.
This adds a standard contract that allows composite question types (such as table questions) to reuse administration and end-user rendering provided by other question types without relying on plugin-specific implementations.
The interface currently defines two responsibilities:
No existing question type is modified by this change.
Motivation
Currently there is no standard way for a question type to expose embeddable rendering.
As a result, plugins must rely on runtime capability detection (
method_exists()) or hard dependencies between plugins.Adding this interface provides a generic extension point that can be reused by any current or future question type.
Backward compatibility
This change is fully backward compatible.
Existing question types continue working without modification.
Only question types implementing the new interface expose the additional capability.
Related