[FIX] #44193, #44192 UI: improve Input\Input naming process.
#10836
Conversation
thibsy
added
bugfix
kitchen sink
php
|
Thank you very much for this @thibsy ! I was just fighting with this as the dedicated names seem to randomly contain a counter and I was unable to figure out, where it came from (e.g. if your form is named, all inputs contain a counter, even if their dedicated name is unique, if I'm not mistaken). I worked around it for the moment, but I love any improvement! Best, |
|
Hi @kergomard, Yes I found this very weird as well. Its fixed in this version. I also made the naming somewhat more predictable by starting to count from 0 at every hierarchy level, so now its i.e. Out of curiosity: for what reason are you using Kind regards, |
* Fixes https://mantis.ilias.de/view.php?id=44193 and https://mantis.ilias.de/view.php?id=44192 * Add `Input\NameSource::withParentName()` to shift responsibility away from inputs. * Add `Input\NameSource::withReset()` to enable reusing the same instance. * Update `HasDynamicInputsNameSource` to support generating indices. * Remove `$parent_name` argument of `Input\Input::withNameFrom()`. * Add `Field\OrderingTableContextRenderer` as temporary workaround for misuse of input mechanics. * Update unit tests and decouple test cases from actual `Input\NameSource` implementation(s). * Add `HasDynamicInputsTemplateRenderer` to render dynamic inputs with indices on client. * Update `file.js` to incorporate `HasDynamicInputsTemplateRenderer`.
thibsy
force-pushed
the
fix/11/ui-input-names
branch
from
413acde to
a686532
Compare
|
Hi @thibsy I'm using them in the context of highly dynamic forms that need to carry their information across multiple screens without displaying it (See: https://docu.ilias.de/go/wiki/wpage_8315_1357). I do not want to save incomplete information, so I create forms with hidden The name for the container I use for an ugly hack: Sometimes after sending a form the users should be warned about something happening. In my case that they are deleting something. Currently I see no other way than to use one of my funny self-calling modals (sorry!). ..but then when confirming in the modal I need to send the form and this is by far more elegant, if the form is named and I can search for the name (currently I just find the form through the structure of the page: run up to the Best, |
3 participants
Hi all,
These bugfixes were implemented with the support and funding of the University of Bern — big thanks!
The PR fixes https://mantis.ilias.de/view.php?id=44193 and https://mantis.ilias.de/view.php?id=44192 by refactoring the naming process of our input components.
The PR is rather large, because I needed to adjust all anonymous and stub implementations of the
Input\NameSourceinterface. So while at it, it seemed the right time to remove them altogether. Many of our unit tests intentionally or unintentionally used real instances of our name sources. This is very wrong from my perspective, since this binds data-processing and rendering tests directly to the implementation details of our name sources. So, if I were to change the default name frominput_Xtoinput_name_X, most of our unit tests suddenly fail. Therefore I replaced these instances in our test cases by mocks, returning either a continuously enumerated naming (with no other logic bound to it), or a static name – the latter of which should be used most of the time.Besides this, I stumbled over two design smells which I have tried to describe in the roadmap.
Kind regards,
@thibsy