Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility
On Wed, Jan 22, 2020 at 8:55 AM Sven Meier wrote:
> Ah, our old friends 'enclosures'!
>
> Problem is that a component inside an enclosure is really inside it only
> during rendering of its markup.
> But the strategy walking through the component hierarchy to render all
> headers doesn't know anything about that enclosure o_O
>
> As it has been written many times on this list, enclosures are best
> avoided in anything than the simplest setup.
>
The recommended solution is to use EnclosureContainer instead of
.
>
> Have fun
> Sven
>
> Am 21. Januar 2020 09:14:28 MEZ schrieb Rob Audenaerde <
> rob.audenae...@gmail.com>:
> >Hi Sven,
> >
> >Thanks for double-checking!
> >
> >The weird thing is that I thought this solved my problem, but when I
> >tried
> >to create the quickstart; I couldn't reproduce it either :o. I seem to
> >have
> >been mistakenly assuming it was this piece of code that fixed the
> >problem.
> >
> >So I tried to build it more towards our application and I saw a
> > that causes this behavior (the
> >isVisibleInHierarchy() is
> >not working there).
> >
> >I attached the quickstart for those who want to experiment with it.
> >
> >-Rob
> >
> >On Mon, Jan 20, 2020 at 7:17 PM Sven Meier wrote:
> >
> >> Hi Rob,
> >>
> >> actually I wasn't able to reproduce the problem on a second try (not
> >> sure what I tested before).
> >>
> >> Can you create a a quickstart showing the problem?
> >>
> >> Sven
> >>
> >> On 20.01.20 13:18, Sven Meier wrote:
> >> > Hi Rob,
> >> >
> >> >> the 'correct' way to solve this?
> >> >
> >> > the component is explicitly added to the Ajax request for an
> >update,
> >> > but decides to hide itself in onConfigure().
> >> > Perfectly valid usecase IMHO, but the head will be rendered
> >> > nevertheless :/
> >> >
> >> > Just tested with 7.x, 8.x and master, this seems to have been that
> >way
> >> > forever.
> >> > But maybe we can improve that in Wicket core?
> >> >
> >> > Sven
> >> >
> >> >
> >> > On 20.01.20 10:36, Rob Audenaerde wrote:
> >> >> Hi all,
> >> >>
> >> >> I recently got some javascript errors that came from behaviors of
> >> >> components that where triggered to be visible or invisible in the
> >dom
> >> >> (using onConfigure()) in an ajax request.
> >> >>
> >> >> Typically something like:
> >> >>
> >> >> Wicket.Ajax: Cannot bind a listener for event "change" on element
> >> >> "format1dd" because the element is not in the DOM
> >> >>
> >> >> I solve this by adding an isVisibleInHierarchy() check in the
> >> >> renderHead()
> >> >> like this:
> >> >>
> >> >> @Override
> >> >>
> >> >> public void renderHead(final Component component, final
> >IHeaderResponse
> >> >> response) {
> >> >> if (component.isVisibleInHierarchy()) {
> >> >> super.renderHead(component, response);
> >> >> }
> >> >> }
> >> >>
> >> >> I was wondering if this is the 'correct' way to solve this? Or am
> >I
> >> >> doing
> >> >> something wrong?
> >> >>
> >> >> Please advise :)
> >> >>
> >> >> -Rob
> >> >>
> >> >
> >> >
> >-
> >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> > For additional commands, e-mail: users-h...@wicket.apache.org
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
>
Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility
Ah, our old friends 'enclosures'!
Problem is that a component inside an enclosure is really inside it only
during rendering of its markup.
But the strategy walking through the component hierarchy to render all headers
doesn't know anything about that enclosure o_O
As it has been written many times on this list, enclosures are best avoided in
anything than the simplest setup.
Have fun
Sven
Am 21. Januar 2020 09:14:28 MEZ schrieb Rob Audenaerde
:
>Hi Sven,
>
>Thanks for double-checking!
>
>The weird thing is that I thought this solved my problem, but when I
>tried
>to create the quickstart; I couldn't reproduce it either :o. I seem to
>have
>been mistakenly assuming it was this piece of code that fixed the
>problem.
>
>So I tried to build it more towards our application and I saw a
> that causes this behavior (the
>isVisibleInHierarchy() is
>not working there).
>
>I attached the quickstart for those who want to experiment with it.
>
>-Rob
>
>On Mon, Jan 20, 2020 at 7:17 PM Sven Meier wrote:
>
>> Hi Rob,
>>
>> actually I wasn't able to reproduce the problem on a second try (not
>> sure what I tested before).
>>
>> Can you create a a quickstart showing the problem?
>>
>> Sven
>>
>> On 20.01.20 13:18, Sven Meier wrote:
>> > Hi Rob,
>> >
>> >> the 'correct' way to solve this?
>> >
>> > the component is explicitly added to the Ajax request for an
>update,
>> > but decides to hide itself in onConfigure().
>> > Perfectly valid usecase IMHO, but the head will be rendered
>> > nevertheless :/
>> >
>> > Just tested with 7.x, 8.x and master, this seems to have been that
>way
>> > forever.
>> > But maybe we can improve that in Wicket core?
>> >
>> > Sven
>> >
>> >
>> > On 20.01.20 10:36, Rob Audenaerde wrote:
>> >> Hi all,
>> >>
>> >> I recently got some javascript errors that came from behaviors of
>> >> components that where triggered to be visible or invisible in the
>dom
>> >> (using onConfigure()) in an ajax request.
>> >>
>> >> Typically something like:
>> >>
>> >> Wicket.Ajax: Cannot bind a listener for event "change" on element
>> >> "format1dd" because the element is not in the DOM
>> >>
>> >> I solve this by adding an isVisibleInHierarchy() check in the
>> >> renderHead()
>> >> like this:
>> >>
>> >> @Override
>> >>
>> >> public void renderHead(final Component component, final
>IHeaderResponse
>> >> response) {
>> >> if (component.isVisibleInHierarchy()) {
>> >> super.renderHead(component, response);
>> >> }
>> >> }
>> >>
>> >> I was wondering if this is the 'correct' way to solve this? Or am
>I
>> >> doing
>> >> something wrong?
>> >>
>> >> Please advise :)
>> >>
>> >> -Rob
>> >>
>> >
>> >
>-
>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility
Hi,
I don't know if it is related or not but I have experienced a similar
problem while using borders. I don't remember the exact situation but I can
try to dig our code base and find out what was it.
On Tue, Jan 21, 2020 at 10:14 AM Rob Audenaerde
wrote:
> Hi Sven,
>
> Thanks for double-checking!
>
> The weird thing is that I thought this solved my problem, but when I tried
> to create the quickstart; I couldn't reproduce it either :o. I seem to have
> been mistakenly assuming it was this piece of code that fixed the problem.
>
> So I tried to build it more towards our application and I saw a
> that causes this behavior (the isVisibleInHierarchy() is
> not working there).
>
> I attached the quickstart for those who want to experiment with it.
>
> -Rob
>
> On Mon, Jan 20, 2020 at 7:17 PM Sven Meier wrote:
>
>> Hi Rob,
>>
>> actually I wasn't able to reproduce the problem on a second try (not
>> sure what I tested before).
>>
>> Can you create a a quickstart showing the problem?
>>
>> Sven
>>
>> On 20.01.20 13:18, Sven Meier wrote:
>> > Hi Rob,
>> >
>> >> the 'correct' way to solve this?
>> >
>> > the component is explicitly added to the Ajax request for an update,
>> > but decides to hide itself in onConfigure().
>> > Perfectly valid usecase IMHO, but the head will be rendered
>> > nevertheless :/
>> >
>> > Just tested with 7.x, 8.x and master, this seems to have been that way
>> > forever.
>> > But maybe we can improve that in Wicket core?
>> >
>> > Sven
>> >
>> >
>> > On 20.01.20 10:36, Rob Audenaerde wrote:
>> >> Hi all,
>> >>
>> >> I recently got some javascript errors that came from behaviors of
>> >> components that where triggered to be visible or invisible in the dom
>> >> (using onConfigure()) in an ajax request.
>> >>
>> >> Typically something like:
>> >>
>> >> Wicket.Ajax: Cannot bind a listener for event "change" on element
>> >> "format1dd" because the element is not in the DOM
>> >>
>> >> I solve this by adding an isVisibleInHierarchy() check in the
>> >> renderHead()
>> >> like this:
>> >>
>> >> @Override
>> >>
>> >> public void renderHead(final Component component, final IHeaderResponse
>> >> response) {
>> >> if (component.isVisibleInHierarchy()) {
>> >> super.renderHead(component, response);
>> >> }
>> >> }
>> >>
>> >> I was wondering if this is the 'correct' way to solve this? Or am I
>> >> doing
>> >> something wrong?
>> >>
>> >> Please advise :)
>> >>
>> >> -Rob
>> >>
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
--
Regards - Ernesto Reinaldo Barreiro
Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility
Hi Sven,
Thanks for double-checking!
The weird thing is that I thought this solved my problem, but when I tried
to create the quickstart; I couldn't reproduce it either :o. I seem to have
been mistakenly assuming it was this piece of code that fixed the problem.
So I tried to build it more towards our application and I saw a
that causes this behavior (the isVisibleInHierarchy() is
not working there).
I attached the quickstart for those who want to experiment with it.
-Rob
On Mon, Jan 20, 2020 at 7:17 PM Sven Meier wrote:
> Hi Rob,
>
> actually I wasn't able to reproduce the problem on a second try (not
> sure what I tested before).
>
> Can you create a a quickstart showing the problem?
>
> Sven
>
> On 20.01.20 13:18, Sven Meier wrote:
> > Hi Rob,
> >
> >> the 'correct' way to solve this?
> >
> > the component is explicitly added to the Ajax request for an update,
> > but decides to hide itself in onConfigure().
> > Perfectly valid usecase IMHO, but the head will be rendered
> > nevertheless :/
> >
> > Just tested with 7.x, 8.x and master, this seems to have been that way
> > forever.
> > But maybe we can improve that in Wicket core?
> >
> > Sven
> >
> >
> > On 20.01.20 10:36, Rob Audenaerde wrote:
> >> Hi all,
> >>
> >> I recently got some javascript errors that came from behaviors of
> >> components that where triggered to be visible or invisible in the dom
> >> (using onConfigure()) in an ajax request.
> >>
> >> Typically something like:
> >>
> >> Wicket.Ajax: Cannot bind a listener for event "change" on element
> >> "format1dd" because the element is not in the DOM
> >>
> >> I solve this by adding an isVisibleInHierarchy() check in the
> >> renderHead()
> >> like this:
> >>
> >> @Override
> >>
> >> public void renderHead(final Component component, final IHeaderResponse
> >> response) {
> >> if (component.isVisibleInHierarchy()) {
> >> super.renderHead(component, response);
> >> }
> >> }
> >>
> >> I was wondering if this is the 'correct' way to solve this? Or am I
> >> doing
> >> something wrong?
> >>
> >> Please advise :)
> >>
> >> -Rob
> >>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
visible.bz2
Description: application/bzip
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility
Hi Rob,
actually I wasn't able to reproduce the problem on a second try (not
sure what I tested before).
Can you create a a quickstart showing the problem?
Sven
On 20.01.20 13:18, Sven Meier wrote:
Hi Rob,
the 'correct' way to solve this?
the component is explicitly added to the Ajax request for an update,
but decides to hide itself in onConfigure().
Perfectly valid usecase IMHO, but the head will be rendered
nevertheless :/
Just tested with 7.x, 8.x and master, this seems to have been that way
forever.
But maybe we can improve that in Wicket core?
Sven
On 20.01.20 10:36, Rob Audenaerde wrote:
Hi all,
I recently got some javascript errors that came from behaviors of
components that where triggered to be visible or invisible in the dom
(using onConfigure()) in an ajax request.
Typically something like:
Wicket.Ajax: Cannot bind a listener for event "change" on element
"format1dd" because the element is not in the DOM
I solve this by adding an isVisibleInHierarchy() check in the
renderHead()
like this:
@Override
public void renderHead(final Component component, final IHeaderResponse
response) {
if (component.isVisibleInHierarchy()) {
super.renderHead(component, response);
}
}
I was wondering if this is the 'correct' way to solve this? Or am I
doing
something wrong?
Please advise :)
-Rob
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility
Hi Rob,
the 'correct' way to solve this?
the component is explicitly added to the Ajax request for an update, but
decides to hide itself in onConfigure().
Perfectly valid usecase IMHO, but the head will be rendered nevertheless :/
Just tested with 7.x, 8.x and master, this seems to have been that way forever.
But maybe we can improve that in Wicket core?
Sven
On 20.01.20 10:36, Rob Audenaerde wrote:
Hi all,
I recently got some javascript errors that came from behaviors of
components that where triggered to be visible or invisible in the dom
(using onConfigure()) in an ajax request.
Typically something like:
Wicket.Ajax: Cannot bind a listener for event "change" on element
"format1dd" because the element is not in the DOM
I solve this by adding an isVisibleInHierarchy() check in the renderHead()
like this:
@Override
public void renderHead(final Component component, final IHeaderResponse
response) {
if (component.isVisibleInHierarchy()) {
super.renderHead(component, response);
}
}
I was wondering if this is the 'correct' way to solve this? Or am I doing
something wrong?
Please advise :)
-Rob
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
