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 <
thiag...@gmail.com> 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 <b...@netzgut.net> 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 <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
> > >
> >
>
>
> --
> Thiago
>
--
Ilya Obshadko
