You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Adrian Wiesmann <aw...@somap.org> on 2012/04/12 16:48:42 UTC
Re: component.isAuto - was: Wicket 1.5: The component(s) below failed
to render (revisited)
Hi
Me again with a follow up to my isAuto() problem.
Setting component.setAuto(true) is quite bad, since Wicket will remove
all components in the detachChildren() method which have the Auto Flag
and which are not an instance of InlineEnclosure. Which all of my
components obviously are not...
While the isAuto(true) results in a nicely rendered component tree, when
you try to click on - say a row in a list - then Wicket throws an error
because the component in question was removed.
Well here we are again. How can I port my renderer which adds components
to the component tree on the fly as I was able to do in Wicket < 1.5?
What was the intention to change the behaviour there?
Regards,
Adrian
On 2/12/12 7:27 PM, Adrian Wiesmann wrote:
> Hello list
>
> Some while ago I posted a few messages to this list where I asked for
> help in finding a problem with Wicket 1.5. I was not able to find the
> bug back then. Now I downloaded the bleeding edge version 1.5.4 and
> tried again. And now I am a step further.
>
> I have that rendering engine where I take an XML file, build an object
> tree from that and have a renderer rendering a Wicket object tree and
> finally Wicket which renders the HTML UI from that.
>
> Now I noticed with version 1.5 of Wicket, that this line in the
> org.apache.wicket.Page.class are the key to my problem (lines 611, 612):
>
> // If not an auto component ...
> if (!component.isAuto() && component.isVisibleInHierarchy())
>
> I noticed that many of my components I add in my renderer on the fly are
> returning isAuto = false on that line (and of course they are visible,
> which adds them to unrenderedComponents and ultimately provokes the error).
>
> I then added this.setAuto(true); in one of my components. And voila, it
> was not in the list of components which failed to render.
>
> So here are my questions:
>
> - What did change from version 1.4.x to version 1.5.x that results in
> this error?
> - Is that a bug in Wicket or do I need to fix my renderer somehow?
> - What side effects does it have if I just add a setAuto(true) to all of
> my components?
>
> Thanks for your help!
>
> Cheers,
> Adrian
>
> ---------------------------------------------------------------------
> 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: component.isAuto - was: Wicket 1.5: The component(s) below failed
to render (revisited)
Posted by Adrian Wiesmann <aw...@somap.org>.
Hi Martin, hi list
I guess I narrowed things down a bit. I was obviously looking at the
wrong places. The problem is with the renderedComponents Set (and not
with the isAuto flag as thought at first).
In the Page class there is that check here:
> // If component never rendered
> if (renderedComponents == null ||
> !renderedComponents.contains(component))
and this method:
> public final void componentRendered(final Component component)
> {
> // Inform the page that this component rendered
> if (getApplication().getDebugSettings().getComponentUseCheck())
> {
This method is obviously only run in the debug mode when the
ComponentUseCheck is activated (which is by default). Which also means
that said Set is only instantiated when ComponentUseCheck is activated.
Which also means the check in the first copy above will not be run when
ComponentUseCheck is false/deactivated.
Now that I deactivated that check, my renderer works again.
So there must be some problem with dynamic components. I looked through
the render methods of 1.5x and 1.4x. While some things changed, the flow
seems to be mostly the same. Nothing obvious.
I'd love to do a minimal quickstart but that won't be very minimal. I'd
have to add most of the renderer, or rewrite parts. I'll see if I find
some time to put together something small.
In the meantime. If somebody has an idea where to look at, I'd be happy
to test things out on my codebase.
Cheers,
Adrian
On 4/12/12 5:02 PM, Martin Grigorov wrote:
> Hi,
>
> On Thu, Apr 12, 2012 at 5:48 PM, Adrian Wiesmann<aw...@somap.org> wrote:
>> Hi
>>
>> Me again with a follow up to my isAuto() problem.
>>
>> Setting component.setAuto(true) is quite bad, since Wicket will remove all
>> components in the detachChildren() method which have the Auto Flag and which
>> are not an instance of InlineEnclosure. Which all of my components obviously
>> are not...
>>
>> While the isAuto(true) results in a nicely rendered component tree, when you
>> try to click on - say a row in a list - then Wicket throws an error because
>> the component in question was removed.
>>
>> Well here we are again. How can I port my renderer which adds components to
>> the component tree on the fly as I was able to do in Wicket< 1.5? What was
>> the intention to change the behaviour there?
>
> It is not clear to me which behavior exactly has changed and now
> causes you troubles.
> Create a minimal quickstart that works on 1.4 and attach it to a ticket in Jira.
>
>>
>> Regards,
>> Adrian
>>
>>
>>
>> On 2/12/12 7:27 PM, Adrian Wiesmann wrote:
>>>
>>> Hello list
>>>
>>> Some while ago I posted a few messages to this list where I asked for
>>> help in finding a problem with Wicket 1.5. I was not able to find the
>>> bug back then. Now I downloaded the bleeding edge version 1.5.4 and
>>> tried again. And now I am a step further.
>>>
>>> I have that rendering engine where I take an XML file, build an object
>>> tree from that and have a renderer rendering a Wicket object tree and
>>> finally Wicket which renders the HTML UI from that.
>>>
>>> Now I noticed with version 1.5 of Wicket, that this line in the
>>> org.apache.wicket.Page.class are the key to my problem (lines 611, 612):
>>>
>>> // If not an auto component ...
>>> if (!component.isAuto()&& component.isVisibleInHierarchy())
>>>
>>> I noticed that many of my components I add in my renderer on the fly are
>>> returning isAuto = false on that line (and of course they are visible,
>>> which adds them to unrenderedComponents and ultimately provokes the
>>> error).
>>>
>>> I then added this.setAuto(true); in one of my components. And voila, it
>>> was not in the list of components which failed to render.
>>>
>>> So here are my questions:
>>>
>>> - What did change from version 1.4.x to version 1.5.x that results in
>>> this error?
>>> - Is that a bug in Wicket or do I need to fix my renderer somehow?
>>> - What side effects does it have if I just add a setAuto(true) to all of
>>> my components?
>>>
>>> Thanks for your help!
>>>
>>> Cheers,
>>> Adrian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: component.isAuto - was: Wicket 1.5: The component(s) below failed
to render (revisited)
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Thu, Apr 12, 2012 at 5:48 PM, Adrian Wiesmann <aw...@somap.org> wrote:
> Hi
>
> Me again with a follow up to my isAuto() problem.
>
> Setting component.setAuto(true) is quite bad, since Wicket will remove all
> components in the detachChildren() method which have the Auto Flag and which
> are not an instance of InlineEnclosure. Which all of my components obviously
> are not...
>
> While the isAuto(true) results in a nicely rendered component tree, when you
> try to click on - say a row in a list - then Wicket throws an error because
> the component in question was removed.
>
> Well here we are again. How can I port my renderer which adds components to
> the component tree on the fly as I was able to do in Wicket < 1.5? What was
> the intention to change the behaviour there?
It is not clear to me which behavior exactly has changed and now
causes you troubles.
Create a minimal quickstart that works on 1.4 and attach it to a ticket in Jira.
>
> Regards,
> Adrian
>
>
>
> On 2/12/12 7:27 PM, Adrian Wiesmann wrote:
>>
>> Hello list
>>
>> Some while ago I posted a few messages to this list where I asked for
>> help in finding a problem with Wicket 1.5. I was not able to find the
>> bug back then. Now I downloaded the bleeding edge version 1.5.4 and
>> tried again. And now I am a step further.
>>
>> I have that rendering engine where I take an XML file, build an object
>> tree from that and have a renderer rendering a Wicket object tree and
>> finally Wicket which renders the HTML UI from that.
>>
>> Now I noticed with version 1.5 of Wicket, that this line in the
>> org.apache.wicket.Page.class are the key to my problem (lines 611, 612):
>>
>> // If not an auto component ...
>> if (!component.isAuto() && component.isVisibleInHierarchy())
>>
>> I noticed that many of my components I add in my renderer on the fly are
>> returning isAuto = false on that line (and of course they are visible,
>> which adds them to unrenderedComponents and ultimately provokes the
>> error).
>>
>> I then added this.setAuto(true); in one of my components. And voila, it
>> was not in the list of components which failed to render.
>>
>> So here are my questions:
>>
>> - What did change from version 1.4.x to version 1.5.x that results in
>> this error?
>> - Is that a bug in Wicket or do I need to fix my renderer somehow?
>> - What side effects does it have if I just add a setAuto(true) to all of
>> my components?
>>
>> Thanks for your help!
>>
>> Cheers,
>> Adrian
>>
>> ---------------------------------------------------------------------
>> 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
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org