Skip to content

UI: a few tweaks to fix roundtrip modals as prompt content - #11105

Closed
schmitz-ilias wants to merge 1 commit into
ILIAS-eLearning:trunkfrom
schmitz-ilias:12_modal_in_prompt
Closed

UI: a few tweaks to fix roundtrip modals as prompt content#11105
schmitz-ilias wants to merge 1 commit into
ILIAS-eLearning:trunkfrom
schmitz-ilias:12_modal_in_prompt

Conversation

@schmitz-ilias

Copy link
Copy Markdown
Contributor

This PR makes roundtrip modals work as the content of prompts. Most of the needed infrastructure is already there from the original implementation of prompts, there are just a few tweaks needed, mostly in rendering.

I'm using prompts in the implementation of ‘Publish as OER‘ Button for Objects, and with these tweaks everything works great. Prompts are a really handy tool for implementing multi-step workflows asynchronously.

Let me know if you want anything done differently.

Cheers, Tim

@schmitz-ilias schmitz-ilias added kitchen sink php Pull requests that update Php code labels Feb 11, 2026

@thibsy thibsy left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @schmitz-ilias,

Thx a lot for bringing this to my attention!

That is actually a very unintended side-effect of making the Input\Form\Standard a valid prompt content (good example of why inheritance is bad). Using a Modal\Roundtrip as content for a Prompt\Prompt defeats its purpose, since it was actually meant to replace it =).

So, if you tell me what contents your roundtrip modal holds, besides a Input\Form\Standard and a MessageBox\MessageBox, we can discuss if something else should become a Prompt\IsPromptContent instead.

In the meantime, I will open a PR myself to remove any unwanted derivatives of Input\Form\Standard from being valid prompt content.

Kind regards,
@thibsy (as UI coordinator)

@thibsy

thibsy commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

See #11853

@schmitz-ilias

Copy link
Copy Markdown
Contributor Author

Hi @thibsy,

I thought roundtrip modals as prompt content was deliberate, to ease the transition to prompts until prompts are actually fully ready to replace modals ^^

As you can see in ‘Publish as OER‘ Button for Objects, I use message boxes in combination with a Chart\ScaleBar in prompts. I don't think this will be possible even with more components tagged with Prompt\IsPromptContent.

That being said, I think how I use the Chart\ScaleBar as a visualization of where the user currently is in their workflow fits kind of neatly into the semantics of prompts, and could be useful in general. How about a withWorkflowStatus or something like that for Prompt\State, with Chart\ScaleBar as the argument?

Further, both forms and message boxes don't properly contribute a title to the prompt (for forms the title is empty, and for message boxes it's the type of the box). The implementation of Prompt\State already has withTitle, but that isn't part of the interface, so custom titles for prompts are not possible "officially" without the roundtrip modal. Prompt\State::withTitle is actually already in use in the ConsecutiveScoringGUI in TA as what looks like a temporary solution, not sure what the long term plan is there.

I'd appreciate it if you could keep #11853 and this PR open until we have a solution, so that we can have a functioning publish button in ILIAS 12 no matter how long this discussion takes.

Best, Tim

@thibsy

thibsy commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

Hi @schmitz-ilias,

Thx for your feedback!

If I understand you correctly, then I believe you raised a valid use-case here: we need a structured way to visualise the progress of the user within a process that consists of multiple prompt (states). I also think that Prompt\State::withWorkflow() would be the appropriate location and mutator. I do however dislike using a Chart\ScaleBar component, even though it works surprisingly well. Let me unpack:

IMO the Chart\ScaleBar works visually, because it conveys to the user:

  • how many steps there are in total
  • what steps there are concretely
  • the progress within that process

But I believe in terms of semantics, the Listing\Workflow components are much more suitable, especially since we can talk about the process in steps already. In #11444 we also used these components to derive necessary information for the Listing\Entity components and render actions of 'available' steps. I believe we could do the same for the progress and actions in prompts. The visualisation IMO could be achieved by modifying the Listing\Workflow to fit a Prompt\Prompt (i.e. Prompt\State) using context rendering, or we could even try to introduce something generic inside the the Component\Progress family which will be used under the hood. We could maybe even utilise a Breadcrumbs\Breadcrumbs to navigate the workflow inside a prompt, allowing users to go back and forth multiple steps at a time. But we could also go for a more minimalistic approach, where we e.g. simply prefix the prompt titles and/or render some x / y steps somewhere.

Is this something you currently see capacity for? Otherwise I would put this sketch on the roadmap, but then we might have to postpone this indefinitely. I will leave the PR's open for the time being.

Prompt titles which are not properly derived from Prompt\IsPromptContent at the moment I would treat separately. Could you provide a fix or create a Mantis issue? Thx!

Let me know if we should discuss this topic on Discord.

Kind regards,
@thibsy (as UI coordinator)

@schmitz-ilias

Copy link
Copy Markdown
Contributor Author

Hi @thibsy,

using Listing\Workflow to enrich prompts with context in the way you propose sounds reasonable and useful. However, it doesn't really fit my use case: the workflow related to the publish button isn't fully encapsulated in the prompts (it can require multiple users to do stuff at different times), and it isn't entirely linear. Further, the workflow should be presented in terms of states, and not in terms of the steps between states.

Beyond that, your proposal sounds a bit too ambitious. I can squeeze in a bit of time until coding complete in October, but not that much.

How about a slightly simpler idea: let Prompt\State carry not only a single component as content, but instead:

  • One component tagged with isPromptContent (maybe renamed to isMainPromptContent) as the primary content, to derive title and actions from.
  • Multiple other components tagged with isSupplementaryPromptContent, which are also rendered into the content of the prompt, but carry no interactivity.

ScaleBar could then be the first component tagged with isSupplementaryPromptContent. In the future, this could be expanded to include other purely visual components, message boxes come to mind (to be rendered without links and actions). This way, e.g. forms in prompts could come with an info text above or below them.

What do you think?

Best, Tim

@thibsy

thibsy commented Aug 20, 2026

Copy link
Copy Markdown
Contributor

Hi @schmitz-ilias,

thx for elaborating. I probably misunderstood the meaning of your Chart\ScaleBar then.

To be honest, I don't really want to embrace the Chart\ScaleBar as an Prompt\IsPromptContent, before we don't look into what the component really represents in this use-use. It feels unnatural to use a chart to represent different states within a workflow. I am sure we can find a more generalised solution that incorporates well with prompts. Maybe this could be achieved by some new type of Listing\Workflow that could represent your scenario and integrates with how I described in my previous comment (Prompt\State::withWorkflow()).

But since making Modal\RoundTrip valid prompt content was our mistake, you should not have pay the price for it. For us it is much more important that we prevent (further) usages of the accidental Modal\RoundTrip component, since this opens doors for any component. I therefore suggest to make the Chart\ScaleBar an Prompt\IsPromptContent until we find a better solution.

I do like your idea about different kinds of prompt contents, and I can see where you are coming from. But I think we could make that distinction more easily and without interfaces, if we treat them as two arguments when factoring a state. We could use a signature like function(IsPromptContent $primary_content, IsPromptContent ...$secondary_content). Do you think this would address all issues that come with more than one prompt content? We could then merge action buttons of primary and secondary (maybe even use different buttons) and simply disregard titles returned by secondary contents, since I assume this would have been the pitfall behind all this, right? Let me know if we should discuss this on Discord.

If you could draw up such a PR it would be highly appreciated =). I discussed this with @oliversamoila today, so this is in agreement with him as well.

Kind regards,
@thibsy & @oliversamoila (as UI coordinator)

@schmitz-ilias

Copy link
Copy Markdown
Contributor Author

Hi @thibsy, sounds good, I'll prepare a PR for "Secondary Prompt Content", and close this one. Thanks for being accomodating!

Best, Tim

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

kitchen sink php Pull requests that update Php code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants