You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Rob Audenaerde <ro...@gmail.com> on 2020/01/20 09:36:36 UTC
AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility
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
Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility
Posted by Martin Grigorov <mg...@apache.org>.
On Wed, Jan 22, 2020 at 8:55 AM Sven Meier <sv...@meiers.net> 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
<wicket:enclosure>.
>
> Have fun
> Sven
>
> Am 21. Januar 2020 09:14:28 MEZ schrieb Rob Audenaerde <
> rob.audenaerde@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
> ><wicket:enclosure> 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 <sv...@meiers.net> 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-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility
Posted by Sven Meier <sv...@meiers.net>.
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 <ro...@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
><wicket:enclosure> 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 <sv...@meiers.net> 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-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
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 <ro...@gmail.com>
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
> <wicket:enclosure> 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 <sv...@meiers.net> 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-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
--
Regards - Ernesto Reinaldo Barreiro
Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility
Posted by Rob Audenaerde <ro...@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
<wicket:enclosure> 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 <sv...@meiers.net> 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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility
Posted by Sven Meier <sv...@meiers.net>.
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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: AjaxEventBehavior/AjaxFormComponentUpdatingBehavior & visibility
Posted by Sven Meier <sv...@meiers.net>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org