Also: nested FormFragment support appears broken. Page initialization somehow triggers the code in t5/core/form-fragment module, that effectively disables input fields and form controls in visible fragments.
On a bright side: Loop/AjaxFormLoop issues that prevented me from upgrade to release version in the past, are likely gone. On Sat, Jan 4, 2020 at 11:44 AM Ilya Obshadko <xf...@xfyre.com> wrote: > I found the place where the old behavior was possibly broken: > https://issues.apache.org/jira/browse/TAP5-2308 > Did anyone else encounter this problem as well? > > On Fri, Jan 3, 2020 at 10:04 PM Ilya Obshadko <xf...@xfyre.com> wrote: > >> Disclaimer: I'm doing a 'long overdue' upgrade from 5.4-beta6, so I might >> be missing something obvious. >> >> Symptoms: >> >> - I'm using a checkbox with *TriggerFragment* mixin and *FormFragment* >> component >> - I'm getting a JavaScript error in Chrome console: RequireJS error: >> require: Invalid configuration, fragment with id policyFragment_0 not >> found >> - Setting a breakpoint on clientId field value change in >> *FormFragment* shows the following: >> - initially clientId value is correct and it's indeed >> *policyFragment_0* (top if the stack is *conduit_get_clientId*) >> - then it's reset to *null* (top of the stack is >> *conduit_set_clientId*) >> - then it's set to *policyFragment* (without trailing *_0*), >> apparently because *TriggerFragment* mixin is calling >> *FormFragment.getClientId()* again; the field is already null at >> this point, so it's just re-initialized with an incorrect value >> >> Apparently the culprit here is the *clientId* field re-initialization; >> any ideas what might be causing this? The setup itself seems to be fairly >> obvious. >> >> -- >> Ilya Obshadko >> >> > > -- > Ilya Obshadko > > -- Ilya Obshadko
