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
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
