You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Thorsten Schöning <ts...@am-soft.de> on 2020/03/18 08:29:02 UTC
Unexpected component-ID "2" for 1 child of repeating view.
Hi all,
I have some test in Wicket which renders a HTML-table using some
"DataView" and in that test I'm distinguishing the cases 0, 1 and 3
result rows. The following is an example for 1 and 3 rows:
> assertNotNull(tester.getComponentFromLastRenderedPage("html:body:meterCnt.someMonth.pnMcsmSummary:resultsContainer:resultsRow:1", true, false), "No first result item available.");
> assertNull( tester.getComponentFromLastRenderedPage("html:body:meterCnt.someMonth.pnMcsmSummary:resultsContainer:resultsRow:2", false, false), "A second result item available.");
> assertNotNull(tester.getComponentFromLastRenderedPage("html:body:meterCnt.someMonth.pnMcsmSummary:resultsContainer:resultsRow:3", true, false), "No third result item available.");
> assertNull( tester.getComponentFromLastRenderedPage("html:body:meterCnt.someMonth.pnMcsmSummary:resultsContainer:resultsRow:4", false, false), "A fourth result item available.");
The above worked for some days, but yesterday I changed the overall
HTML-template to add additional panels and the tests above stopped to
work. It's important to note that the added panel has nothing to do
with that table, it is completely unrelated in the header-part of the
body of the template and therefore shouldn't have any influence on the
table.
Nevertheless, the tests fail now, because the IDs of the generated
result rows seem to be off by one. In the debugger I can see that the
number of result rows is still as expected, but the former ID "1" has
changed to "2" now for some reason. So after reimplementing the test
to check "rows.getItemCount()" instead of concrete component-IDs, they
succeed again. But checking availability of expected components felt
more correct to me.
Any idea what the cause for the changed child-component-ID might be?
Looking at "RepeatingView", it seems the generated ID is neither
static nor am I aware of reusing components during tests. And I don't
think that the newly added panel has any influence, I guess it's more
on execution order of tests or something. But all my tests are
executed in order 0, 1 and 3 results and that didn't change since the
days before as well.
As I have changed the tests this is not a big deal currently, but I'm
wondering what I'm missing here. Thanks for your thoughts!
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Unexpected component-ID "2" for 1 child of repeating view.
Posted by Sven Meier <sv...@meiers.net>.
Hi,
that looks fine.
I was thinking of longer tests:
- start page
- click link*
- click button*
- ...
- check table contents
(* initiating a page render)
You could put a breakpoint in RepeatingView#newChildId() and check who's
creating new items.
Have fun
Sven
On 18.03.20 12:38, Thorsten Schöning wrote:
> Guten Tag Sven Meier,
> am Mittwoch, 18. März 2020 um 10:04 schrieben Sie:
>
>> what IItemReuseStrategy are you using?
>> DefaultItemReuseStrategy creates new items on each render, which leads
>> to new ids.
> I didn't care yet and can't find anything regarding that strategy, so
> I guess it's the default one. While I indeed render the same page
> multiple times within the same test, things look like the following:
>
>> try (VwrCtxThreadScoped scopedCtx = new VwrCtxThreadScoped(ctx0))
>> {
>> VwrHtmlApp app = new VwrHtmlApp();
>> WicketTester tester = new WicketTester(app);
>> VwrHtmlPage page = new VwrPgMcsmSummary();
>>
>> tester.startPage(page);
>> this.wicketAssertBase(tester, page);
>> tester.assertVisible("html:body:meterCnt.someMonth.pnMcsmSummary:resultsContainer:noResults");
>> tester.destroy();
>> }
> So each invocation works with new instances of everything in theory.
> Even the results to render themself change, as those are contained in
> "ctx0", "ctx1" and "ctx3".
>
> So, shouldn't each of those blocks start freshly in theory?
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Unexpected component-ID "2" for 1 child of repeating view.
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Sven Meier,
am Mittwoch, 18. März 2020 um 10:04 schrieben Sie:
> what IItemReuseStrategy are you using?
> DefaultItemReuseStrategy creates new items on each render, which leads
> to new ids.
I didn't care yet and can't find anything regarding that strategy, so
I guess it's the default one. While I indeed render the same page
multiple times within the same test, things look like the following:
> try (VwrCtxThreadScoped scopedCtx = new VwrCtxThreadScoped(ctx0))
> {
> VwrHtmlApp app = new VwrHtmlApp();
> WicketTester tester = new WicketTester(app);
> VwrHtmlPage page = new VwrPgMcsmSummary();
>
> tester.startPage(page);
> this.wicketAssertBase(tester, page);
> tester.assertVisible("html:body:meterCnt.someMonth.pnMcsmSummary:resultsContainer:noResults");
> tester.destroy();
> }
So each invocation works with new instances of everything in theory.
Even the results to render themself change, as those are contained in
"ctx0", "ctx1" and "ctx3".
So, shouldn't each of those blocks start freshly in theory?
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Unexpected component-ID "2" for 1 child of repeating view.
Posted by Sven Meier <sv...@meiers.net>.
Hi Thorsten,
what IItemReuseStrategy are you using?
DefaultItemReuseStrategy creates new items on each render, which leads
to new ids.
Maybe testing your additional panels initiates additional pages renderings?
Have fun
Sven
On 18.03.20 09:29, Thorsten Schöning wrote:
> Hi all,
>
> I have some test in Wicket which renders a HTML-table using some
> "DataView" and in that test I'm distinguishing the cases 0, 1 and 3
> result rows. The following is an example for 1 and 3 rows:
>
>> assertNotNull(tester.getComponentFromLastRenderedPage("html:body:meterCnt.someMonth.pnMcsmSummary:resultsContainer:resultsRow:1", true, false), "No first result item available.");
>> assertNull( tester.getComponentFromLastRenderedPage("html:body:meterCnt.someMonth.pnMcsmSummary:resultsContainer:resultsRow:2", false, false), "A second result item available.");
>> assertNotNull(tester.getComponentFromLastRenderedPage("html:body:meterCnt.someMonth.pnMcsmSummary:resultsContainer:resultsRow:3", true, false), "No third result item available.");
>> assertNull( tester.getComponentFromLastRenderedPage("html:body:meterCnt.someMonth.pnMcsmSummary:resultsContainer:resultsRow:4", false, false), "A fourth result item available.");
> The above worked for some days, but yesterday I changed the overall
> HTML-template to add additional panels and the tests above stopped to
> work. It's important to note that the added panel has nothing to do
> with that table, it is completely unrelated in the header-part of the
> body of the template and therefore shouldn't have any influence on the
> table.
>
> Nevertheless, the tests fail now, because the IDs of the generated
> result rows seem to be off by one. In the debugger I can see that the
> number of result rows is still as expected, but the former ID "1" has
> changed to "2" now for some reason. So after reimplementing the test
> to check "rows.getItemCount()" instead of concrete component-IDs, they
> succeed again. But checking availability of expected components felt
> more correct to me.
>
> Any idea what the cause for the changed child-component-ID might be?
>
> Looking at "RepeatingView", it seems the generated ID is neither
> static nor am I aware of reusing components during tests. And I don't
> think that the newly added panel has any influence, I guess it's more
> on execution order of tests or something. But all my tests are
> executed in order 0, 1 and 3 results and that didn't change since the
> days before as well.
>
> As I have changed the tests this is not a big deal currently, but I'm
> wondering what I'm missing here. Thanks for your thoughts!
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org