Re: TriggerFragment/FormFragment not working properly in 5.4.5
Ilya Obshadko <[email protected]> Mon, 6 Jan 2020 09:46:26 +0800
| Newsgroups | gmane.comp.java.tapestry.user |
|---|---|
| Message-ID | <CAAT_KPLAiMe5DjLTAesM1p4wRvAP36ZmN-M581Wwm44rVW=hVQ@mail.gmail.com> |
--000000000000842dea059b6ed4fc Content-Type: text/plain; charset="UTF-8" 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 <[email protected]> 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 <[email protected]> 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 --000000000000842dea059b6ed4fc--