Repository navigation
Conversation
Add new variant of `Field\Hidden` component, which accepts multiple values associated to one key, instead of a single value.
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
Add new `Render\ContextMatcher` which is used inside all our `Render\RendererFactory` instances to determine contexts more consistently.
thibsy
added
bugfix
kitchen sink
improvement
php
thibsy
force-pushed
the
feature/12/ui-confirmation-prompt
branch
from
October 27, 2026 21:11
899c9a9 to
df25f2a
Compare
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
With 682519346263e783dfda6775ad3242f1640c6a61 the client-side facility changed. This fixes the outdated usages.
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
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>
This allows destructuring and declarations of simple objects on one line. This happens farily often, especially import statements.
thibsy
force-pushed
the
feature/12/ui-confirmation-prompt
branch
from
October 27, 2026 22:59
df25f2a to
061b23b
Compare
Contributor
Author
|
It definitely deserves some CSS love by the forge in the future.. (ping @BettyFromHH) 
|
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
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.
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\Entitycomponent from @fhelfer's PR and to encapsulate the coupling betweenC\Input\Container\Form\StandardandC\Listing\Entity\Standardcomponents (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\EntityandC\Listing\Entitycomponent families, which streamlined the overall architecture built around a newC\Entity\EntityRetrieval. To build confirmation prompts we obviously still needed to makeC\Listing\Entity\Standarda viableC\Prompt\IsPromptContentcomponent, 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\HiddenListcomponent, which is somewhat similar to the proposedC\Input\Field\Entityin terms of carrying the technical identifiers inside the request body. This way, consumers can accumulate multiple identifiers under one key.C\Input\Field\Hiddendid not support this directly.During testing I ran into the following issues:
Thats it in a nutshell.
Kind regards,
@thibsy (as UI coordinator)