Hi,

we ran into some issues with nested fragments and disabled fields, too.
Instead of using the mixin we ended up triggering the fragments ourselves
with CoffeeScript:

define ['jquery', 't5/core/events', 't5/core/form-fragment'], ($, events) ->

    fieldChange = (event) ->
        $('#formFragmentId').trigger events.formfragment.changeVisibility,
            visible: <visibility criteria>

    $ ->
        $('input[type=radio][name=fieldName]').change fieldChange
        fieldChange()

If I remember correctly, it wasn't easily fixable "from the outside", so
we're using this workaround instead.

– Ben


On Mon, Jan 6, 2020 at 2:46 AM Ilya Obshadko <xf...@xfyre.com> wrote:

> 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
>

Reply via email to