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 <ilya.obsha...@gmail.com>
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 <
> 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
>
>
--
Ilya Obshadko
