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
>