ks: section dropdown

[alex40724]

This is a follow up of #10298.

This PR adds a Section View Control to the Input View Controls including Dropdowns as middle items.

Use cases are navigational elements like here:
https://docu.ilias.de/goto_docu_wiki_wpage_7518_1357.html

The original PR is moved from the legacy view control to the input view control.

[thibsy]

Hi @alex40724,

Thx a lot for working on this again, and special thanks for moving the proposal towards the new input infrastructure!

I really appreciate your effort, but the proposal does not fit into the current architecture of our inputs yet. It i.e. does not use a surrounding <form> and uses buttons for all its actions instead. I therefore want to ask how you like to proceed before I would do a full review here.

From my perspective, we could still accept your previous solution from #10298 with the minor corrections, even though we recently marked these view controls as deprecated. Implementing this properly inside our inputs infrastructure brings up a lot of unanswered questions about how we want to handle e.g. the previous- and next-actions, or what kinds of sections and structure should be used (since the payload has to be transmitted as form body). I would therefore suggest to pursue this at a later point, since this could become costly real quick.

Let me know how you want to proceed. If you want to implement this for the inputs, I am happy to discuss the topic on Discord with you.

Kind regards,
@thibsy (as UI coordinator)

[alex40724]

Hi @thibsy,

thanks for your feedback. Could you please make a list of all open points that needs to be adressed? This would allow me to understand all open issues and work on possible suggestions. I may open a PR against the old structure, too.

Thanks,
@alex40724

[thibsy]

Hi @alex40724,

Sure, no problem. Without doing a concrete review, to spare our resources as well, I think the most important points which need to be addressed are:

• the section input must be properly embedded in a view control container, which ultimately renders the input inside a form that uses an action provided by the consumer. This action is the only point of interaction to determine what section was chosen.
• the section input must operate with HTML elements that are considered by the surrounding form element, so respective values end up in $_GET once the form is submitted. This could be hidden inputs, put behind some control elements, or simply a select.
• the section input must encapsulate its 'previous' and 'next' actions inside the input, meaning it should be handled by the UI framework (only one endpoint from consumer). Probably a similar concept like for Input\ViewControl\Pagination can be used, working with index of sections.
• the section input must know about all available sections during construction. The sections need to be structured in a way that operates with our input processing (withInput(), withValue(), withRequest(), etc), probably as key-value pair. How the Button\Month can be incorporated here is unclear; maybe as Input\Field\DateTime or new dedicated Input\Field\Month instead of an array of sections; maybe it should be dropped (see last point).
• the section input could accept sections as key-value pairs but work with a Input\Field\Select internally. To me the section view control feels like a select, where position/order of options matters to navigate them. This navigation could be implemented by the view control, while all other data processing is simply delegated to a select internally. This should be evaluated more closely during an implementation.
• the section input should be streamlined. It should probably always look the same, no difference between Button\Standard, Button\Month or Dropdown\Dropdown. Sections should always be listed and chosen the same way. Maybe always show like a dropdown. Maybe use a simple select for the first iteration.

I hope that helps. If something is unclear, please let me know =).

Kind regards,
@thibsy (as UI coordinator)