TriggerFragment/FormFragment not working properly in 5.4.5

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: TriggerFragment/FormFragment not working properly in 5.4.5

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
Reply | Threaded
Open this post in threaded view
|

Re: TriggerFragment/FormFragment not working properly in 5.4.5

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
Reply | Threaded
Open this post in threaded view
|

Re: TriggerFragment/FormFragment not working properly in 5.4.5

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
>
Reply | Threaded
Open this post in threaded view
|

Re: TriggerFragment/FormFragment not working properly in 5.4.5

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
Reply | Threaded
Open this post in threaded view
|

Re: TriggerFragment/FormFragment not working properly in 5.4.5

Thiago H de Paula Figueiredo
In reply to this post by Ben Weidig
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
Reply | Threaded
Open this post in threaded view
|

Re: TriggerFragment/FormFragment not working properly in 5.4.5

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
>