|
|
|
|
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
|
|
|
I found the place where the old behavior was possibly broken:
https://issues.apache.org/jira/browse/TAP5-2308Did 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
|
|
|
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
|
|
|
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
>
|
|
|
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
|
|
|
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
|
|
|
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
>
|
|
|
In reply to this post by Thiago H de Paula Figueiredo
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
|
|
|
There's a bug about it which is 1 year old already:
https://issues.apache.org/jira/projects/TAP5/issues/TAP5-2604But 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
|
|
Locked
