UI: a few tweaks to fix roundtrip modals as prompt content - #11105
UI: a few tweaks to fix roundtrip modals as prompt content#11105schmitz-ilias wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
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)
|
See #11853 |
|
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 That being said, I think how I use the 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 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 |
|
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 IMO the
But I believe in terms of semantics, the 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 Let me know if we should discuss this topic on Discord. Kind regards, |
|
Hi @thibsy, using 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
What do you think? Best, Tim |
|
Hi @schmitz-ilias, thx for elaborating. I probably misunderstood the meaning of your To be honest, I don't really want to embrace the But since making 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 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, |
|
Hi @thibsy, sounds good, I'll prepare a PR for "Secondary Prompt Content", and close this one. Thanks for being accomodating! Best, Tim |
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