Yes I know.
This is something we just silently ignored over the last years, as it
was not affecting any functionality.
But now with the red flashing debug window it's getting annoying. (So
some good has come from that ) And we were wondering if what we did was
actually wrong ;)
Thijs
On 17-10-2012 10:01, Bas Gooren wrote:
And to add to this: make sure you call
setOutputMarkupPlaceholderTag(true) before you render the (possibly
invisible) component for the first time.
Suppose your component is hidden (setVisible(false)) on the first render.
If you now call setOutputMarkupPlaceholderTag(true) in the ajax
request that needs to repaint the component, it still won't work as
there is no markup placeholder.
So call setOutputMarkupPlaceholderTag(true) when you create the
component :-)
Met vriendelijke groet,
Kind regards,
Bas Gooren
Op 17-10-2012 9:57, schreef Martin Grigorov:
On Wed, Oct 17, 2012 at 9:52 AM, Thijs <vonk.th...@gmail.com> wrote:
On 17-10-2012 9:40, Martin Grigorov wrote:
Hi,
On Wed, Oct 17, 2012 at 9:27 AM, Thijs <vonk.th...@gmail.com> wrote:
Revisiting this.
I'm still having some troubles with this.
Say I have:
Label a;
add(a = Label(...)
{ onConfigure(){setVisible(*false due to some condition*)}});
a.setOutputMarkupId(true);
add(new AjaxLink(..){
onClick(AjaxRequestTarget t){t.add(a);}
};
In this case the debug window will start calling mayhem as clearly
label
a
is not on the page so it can't find the component to update.
So my question is:
Is it common practice to always do something like:
AjaxLink(){
onClick(AjaxRequestTarget t){
if(a.isVisibleInHierarchy())
t.add(a);
}
}
Or should I always do:
add(a = Label(...)
{ onConfigure(){setVisible(*false due to some condition*)}});
a.setOutputMarkupId(true);
showPhoto.setOutputMarkupPlaceholderTag(true);
I think you need : a.setOutputMarkupPlaceholderTag(true), not sure
what 'showPhoto' is.
Yes correct.
setOutputMarkupPlaceholderTag(true) calls setOutputMarkupId(true) for
you, so there is no need to call both of them.
Or could the AjaxRequestTarget be modified to do the
isVisibleInHierarchy()
before actually rendering the component?
This is possible but it will lead to more confusion. In this case your
component wont be modified at all and there wont be any indication. We
can add a WARN in the logs but my experience shows that not many
developers actually follow the logs.
Not sure what the issue would be with this. As the component isn't
visible
on the anyway.
Exactly! The component is invisible and your logic modifies something
in it and tries to repaint it. So it seems you actually want to make
it visible. But with your proposal to just ignore it if it is
invisible then this will be very confusing, IMO.
But basically your answer is: Yes when you add a component to the
AjaxRequestTarget that might not be visible, make sure that
setOutputMarkupPlaceholderTag(true) is always called on that
component?!
Right.
Thanks
On 6-9-2012 22:47, Thijs Vonk wrote:
OK thnx will give it a try
On 6/9/12 22:39, Igor Vaynberg wrote:
isVisibleInHierarchy() will make sure all parents are visible as
well
-igor
On Thu, Sep 6, 2012 at 1:27 PM, Thijs Vonk <vonk.th...@gmail.com>
wrote:
Hi,
We have partial page updates all over a page. So panels and
components
all
over the place that need Ajax updates.
We're using an Interface on those components and with an
IVisitor we
traverse the component tree and add every component to the
target that
has
this interface.
But during development we see that we get errors in the ajax
debug log
when
these components have an invisible state. These components
themselves
can
have this state but some of the times, the parent component is
invisible. In
these cases when such a hidden component is added to the
AjaxRequestTarget
we get an error in the ajax debug log.
Adding the isVisible check before adding the component to the
target
could
save us in some situations but not all (as it might get visible or
invisible) at a later state.
How can I prevent these components from being added to the
AjaxRequestTarget? Or from the error being thrown? I had hoped
that a
component being in an invisible state (somewhere in the tree)
wouldn't
get
rendered. It's not really a problem in a 'deployment'
situation, but
it's
not 'nice' either.
Thijs
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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