TriggerFragment/FormFragment not working properly in 5.4.5

[Ilya Obshadko]

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]

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 <[hidden email]> 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]

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 <[hidden email]> 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 <[hidden email]> 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

[Ben Weidig]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>

[Ilya Obshadko-2]

The amount of code broken by this issue is substantial. I'd rather consider
maintaining my own fork from 5.4-beta6 (outdated dependencies is my only
concern about this version, everything else works perfectly).

On Mon, Jan 6, 2020 at 4:26 PM Ben Weidig <[hidden email]> wrote:

> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >
>

--
Ilya Obshadko

[Thiago H de Paula Figueiredo]

Do you happen to know how to fix this from the outside? If you create a
pull request, after testing, I'll happily apply it.

On Mon, Jan 6, 2020 at 5:26 AM Ben Weidig <[hidden email]> wrote:

> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >
>

--
Thiago

[Ben Weidig]

Hi Thiago,

with "from the outside" I meant triggering them manually, sorry.

But if I find some time, I'll check it out again, and if I can fix it on
Tapestry's side, I'll create a pull request.

Ben

On Wed, Jan 8, 2020 at 1:52 AM Thiago H. de Paula Figueiredo <
[hidden email]> wrote:

> Do you happen to know how to fix this from the outside? If you create a
> pull request, after testing, I'll happily apply it.
>
> On Mon, Jan 6, 2020 at 5:26 AM Ben Weidig <[hidden email]> wrote:
>
> > 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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
> > >
> >
>
>
> --
> Thiago
>

[Ilya Obshadko-2]

I think I found the reason: when *events.formfragment.changeVisibility* is
triggered, all 'input' descendants of the fragment are indiscriminately
updated, including t:formdata fields which may belong to nested fragments.
This forces Tapestry to treat them as enabled during a subsequent
submission, and submission fails due to validation errors. I think this can
be fixed by excluding input fields belonging to nested fragments from the
update. Visibility change event should not touch anything that belongs to
nested fragments - then it's going to work correctly.

On Wed, Jan 8, 2020 at 2:52 AM Thiago H. de Paula Figueiredo <
[hidden email]> wrote:

> Do you happen to know how to fix this from the outside? If you create a
> pull request, after testing, I'll happily apply it.
>
> On Mon, Jan 6, 2020 at 5:26 AM Ben Weidig <[hidden email]> wrote:
>
> > 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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
> > >
> >
>
>
> --
> Thiago
>

--
Ilya Obshadko

[Ilya Obshadko-2]

There's a bug about it which is 1 year old already:
https://issues.apache.org/jira/projects/TAP5/issues/TAP5-2604

But the issue itself was introduced by Howard's commit back in 2015. I'm
quite surprised by the fact that nobody ran into this issue since then.
FormFragment is not heavily used?


On Tue, Feb 25, 2020 at 11:08 AM Ilya Obshadko <[hidden email]>
wrote:

> I think I found the reason: when *events.formfragment.changeVisibility*
> is triggered, all 'input' descendants of the fragment are indiscriminately
> updated, including t:formdata fields which may belong to nested
> fragments. This forces Tapestry to treat them as enabled during a
> subsequent submission, and submission fails due to validation errors. I
> think this can be fixed by excluding input fields belonging to nested
> fragments from the update. Visibility change event should not touch
> anything that belongs to nested fragments - then it's going to work
> correctly.
>
> On Wed, Jan 8, 2020 at 2:52 AM Thiago H. de Paula Figueiredo <
> [hidden email]> wrote:
>
>> Do you happen to know how to fix this from the outside? If you create a
>> pull request, after testing, I'll happily apply it.
>>
>> On Mon, Jan 6, 2020 at 5:26 AM Ben Weidig <[hidden email]> wrote:
>>
>> > 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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]>
>> 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
>> > >
>> >
>>
>>
>> --
>> Thiago
>>
>
>
> --
> Ilya Obshadko
>
>

--
Ilya Obshadko