Thijs,
We've been working with wicket for a number of years now, and yes, we
have two rules (that feel very natural after those years...):
- Do I need to replace this component over AJAX: call
setOutputMarkupId(true)
- Idem, but can the component itself be hidden (usually quite visible as
we override onConfigure() to control visibility): call
setOutputMarkupPlaceholderTag(true).
The beauty of wicket is that it is quite clear if you forget.
The "AJAX Debug" window in the bottom right of your browser window will
turn red, and once you open it, will say it cannot replace a component
since it's not in the markup.
Met vriendelijke groet,
Kind regards,
Bas Gooren
Op 17-10-2012 9:52, schreef Thijs:
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.
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?!
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
