Skip to content

[FEATURE] UI: Confirmation Prompts and more - #12303

Merged
thibsy merged 9 commits into
ILIAS-eLearning:trunkfrom
srsolutionsag:feature/12/ui-confirmation-prompt
Oct 28, 2026
Merged

[FEATURE] UI: Confirmation Prompts and more#12303
thibsy merged 9 commits into
ILIAS-eLearning:trunkfrom
srsolutionsag:feature/12/ui-confirmation-prompt

Conversation

@thibsy

@thibsy thibsy commented Oct 27, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Hi all,

I have created this PR during the review process of #10031 and #11987. It addresses several of the different things I was working on, because they are all somewhat related and entangled. Credits definitely go to @fhelfer and @schmitz-ilias as well here, because they laid down some important groundwork for his.

I ultimately decided against the C\Input\Field\Entity component from @fhelfer's PR and to encapsulate the coupling between C\Input\Container\Form\Standard and C\Listing\Entity\Standard components (for confirmation prompts) inside the UI framework. The main reason being that it did not feel right to implement a presentational input, the first of its kind, just to solve a compositional issue, especially since (almost) everything to build a confirmation prompt already existed inside the UI framework.

I believe we can encapsulate this coupling inside the UI framework once we find an appropriate higher-order component, where the confirmation prompt is merely an implementation detail, e.g. of an object administration page. Until we have such components, we should think about a centralised builder/director facility, which mitigates the compositional issues we still have (or run into). This could be helpful for other use cases as well.

I did however keep the changes to the C\Entity and C\Listing\Entity component families, which streamlined the overall architecture built around a new C\Entity\EntityRetrieval. To build confirmation prompts we obviously still needed to make C\Listing\Entity\Standard a viable C\Prompt\IsPromptContent component, which I also adopted from @fhelfer's proposal. I update the context rendering, so we can reuse the same entity template.

To provide some syntactic sugar, I have also implemented a new C\Input\Field\HiddenList component, which is somewhat similar to the proposed C\Input\Field\Entity in terms of carrying the technical identifiers inside the request body. This way, consumers can accumulate multiple identifiers under one key. C\Input\Field\Hidden did not support this directly.

During testing I ran into the following issues:

  • Async responses contained unrelated JavaScript code. This was already mentioned by @schmitz-ilias and @alex40724 on different occasions and I finally found a solution that works until we have mitigated the issue by getting rid of inline JavaScript registration and/or implementing proper routing.
  • JavaScript code of async content was not properly executed. There was a mantis issue and proposal ([Fix] #0048244 UI/Prompt: async state roundtrips can break client JS (forms / scripts / close-redirect) #11986) by @fhelfer about this. His solution did however lead to another problem below, which is one of the reasons I ultimately started a larger refactoring of the client-side facilities.
  • JavaScript code of async content was potentially executed more than once. There were cases where identical JavaScript (logic wise) was provided by the same endpoint multiple times, potentially performing global actions more than once leading to errors or faulty behaviour. To avoid this I created a cache for states and fingerprints of inserted scripts, to ensure JavaScript code is executed exactly once.
  • File uploads did not work because form submission were intercepted by the prompt. This was also reported here and was the second reason that led to my larger refactoring. In the end I solved this by utilising JavaScript's event-loop properly and intercept events that bubbled up to the parent element (the prompt).

Thats it in a nutshell.

Kind regards,
@thibsy (as UI coordinator)

@thibsy thibsy added bugfix kitchen sink improvement php Pull requests that update Php code javascript Pull requests that update Javascript code css/html Pull requests that propose changes to CSS/SCSS or HTML files. translations Pull requests that propose changes to ILIAS language files. labels Oct 27, 2026
@thibsy
thibsy force-pushed the feature/12/ui-confirmation-prompt branch 2 times, most recently from df25f2a to 061b23b Compare October 27, 2026 22:59
@thibsy

thibsy commented Oct 27, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

It definitely deserves some CSS love by the forge in the future.. (ping @BettyFromHH)

image

@thibsy
thibsy force-pushed the feature/12/ui-confirmation-prompt branch from 061b23b to f0ef46d Compare October 28, 2026 15:29
thibsy added 2 commits October 28, 2026 16:31
@thibsy
[FEATURE] UI: introduce Field\HiddenList component
819b476 
Add new variant of `Field\Hidden` component, which accepts multiple
values associated to one key, instead of a single value.
@thibsy
[FIX] #47234 UI: stop sync JS leaking into async responses
aca8a4c 
Update `UI\Renderer::renderAsync()` so JavaScript is cleared
before rendering chain starts.

This is necessary because ILIAS controllers contribute parts
of the final page independently and regardless of sync/async
state. Rendering registers JavaScript as a side effect, making
async responses contain leaked JavaScript from unrelated UI
components.

This is a reminder that we want proper routing inside ILIAS.

See:
- https://docu.ilias.de/go/wiki/wpage_8780_1357
- https://mantis.ilias.de/view.php?id=47234
This was referenced Oct 28, 2026
Closed
Closed
thibsy and others added 7 commits October 28, 2026 16:52
@thibsy
[REFACTOR] UI: add Render\ContextMatcher facility
00d0a04 
Add new `Render\ContextMatcher` which is used inside all our
`Render\RendererFactory` instances to determine contexts more
consistently.
@thibsy
[REFACTOR] UI: improve Prompt component family
d219f7a 
This improves the overall structure of the `Prompt` component
family, especially their client-side facilities. Concretely:

* Modernised the client-side architecture to fit existing practices
* Streamlined the compisition of the `Prompt\State\State` components
* Improved capture functionality of forms and anchors inside prompts
* Updated prompt HTML/CSS and used BEMIT naming conventions
* Updated how JS code of async responses is added (exactly once)
* Added support for `Form\Standard::withAdditionalFormAction()`
* Added caching of prompt states that improves multi-stel processes
* Added error handling and the display of a failure message box
* Added explicit `Prompt\State\Instruction` to determine actions
* Added php and javascript unit tests covering the functionality
@thibsy
[FIX] MetaData: update JS usage of Prompt\Prompt
2d61cee 
With 682519346263e783dfda6775ad3242f1640c6a61 the client-side
facility changed. This fixes the outdated usages.
@thibsy
[FIX] #47956 UI: file upload inside Prompt\Prompt
341bda5 
With 682519346263e783dfda6775ad3242f1640c6a61 the client-side
facility changed. This is a prerequisite that allows the
`Field\File` component to properly handle file uploads before
the form inside a `Promot\Prompt` is submitted asynchronously.

Until now the form was submitted before all file uploads were
completed, making it impossible to use file inputs in prompts.

See: https://mantis.ilias.de/view.php?id=47956
@thibsy @fhelfer
[FEATURE] UI: make Entity viable IsPromptContent
67eb68f 
This makes the `Listing\Entity\Standard` extend from
`Prompt\IsPromptContent`, making it usable for prompts.
The listing and its entities received context rendering
to account for the limited space inside the prompt. In
addition we have streamlined the overall architecture
by focusing on the new `Entity\EntityRetrieval`, which
fits more naturally into the current architecture of
the UI framework.

Combined with 68aa9d2
this allows us to implement confirmations prompts for
single or multiple entities consistently in ILIAS.

Co-authored-by: Fabian Helfer <82493694+fhelfer@users.noreply.github.com>
@thibsy
[FIX] Style: re-compile delos stylesheet.
327b56d
@thibsy
[CI] ignore object-curly-newline eslint rule
4ee2835 
This allows destructuring and declarations of simple
objects on one line. This happens farily often, especially
import statements.
@thibsy
thibsy force-pushed the feature/12/ui-confirmation-prompt branch from f0ef46d to 4ee2835 Compare October 28, 2026 15:52
@thibsy

thibsy commented Oct 28, 2026

Copy link
Copy Markdown
Contributor Author

To clarify my proceedings here: This PR contains an adjusted version of #10031 which is contained in 67eb68f. There have only been minor adjustments to the public API since, which has been communicated with JF and we will announce them at the upcoming JF, after merge.

The other 8 commits were created by myself while working on other tasks around the C\Prompt component family. These adjustments were almost all implementation details, for which I did not need JF approval. But it was a lot easier to combine them all in one PR, since opening different PR's and integrating them one after the other, especially close before coding-completed, would have been quite cumbersome. This is what makes the PR larger than the initial proposal from @fhelfer.

@thibsy
thibsy merged commit 70b2302 into ILIAS-eLearning:trunk Oct 28, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@thibsy thibsy

@oliversamoila oliversamoila

Labels

bugfix css/html Pull requests that propose changes to CSS/SCSS or HTML files. improvement javascript Pull requests that update Javascript code jour fixe kitchen sink php Pull requests that update Php code translations Pull requests that propose changes to ILIAS language files.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@thibsy @oliversamoila