Re: Unexpected component-ID "2" for 1 child of repeating view.
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();
WicketTestertester = 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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to change the target of some form-action to some configured value?
Guten Tag Sven Meier, am Mittwoch, 18. März 2020 um 10:41 schrieben Sie: > have you tried overriding #getActionUrl()? No, that was exactly what I was looking for and must have missed. Thanks, it works as expected. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Unexpected component-ID "2" for 1 child of repeating view.
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();
> WicketTestertester = 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.schoen...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to change the target of some form-action to some configured value?
Hi Thorsten, have you tried overriding #getActionUrl()? Sven On 18.03.20 10:19, Thorsten Schöning wrote: Hi all, I'm rendering a web page for offline use, but am playing around with integration into the parent web site where that offline page comes from. The current approach is to simply show the same auth-form used by the online variant itself already and to simply POST credentials there. The problem is that Wicket generates a local action-target for the form and I don't see any way to override that behaviour. Look at the following examples: vs. What I'm currently doing is implementing a custom "AbstractTransformerBehavior" simply changing the action-attribute in the generated markup using some configured value. Is that the easiest/preferred approach? Searchign for that topic I only found Ajax-related things, which is not what I'm interested in. But I couldn't find somethign to simply set the target or override the strategy how that is calculated or such. Thanks for your hints! Mit freundlichen Grüßen, Thorsten Schöning - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
How to change the target of some form-action to some configured value?
Hi all, I'm rendering a web page for offline use, but am playing around with integration into the parent web site where that offline page comes from. The current approach is to simply show the same auth-form used by the online variant itself already and to simply POST credentials there. The problem is that Wicket generates a local action-target for the form and I don't see any way to override that behaviour. Look at the following examples: > method="post"[...] What I'm currently doing is implementing a custom "AbstractTransformerBehavior" simply changing the action-attribute in the generated markup using some configured value. Is that the easiest/preferred approach? Searchign for that topic I only found Ajax-related things, which is not what I'm interested in. But I couldn't find somethign to simply set the target or override the strategy how that is calculated or such. Thanks for your hints! Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Unexpected component-ID "2" for 1 child of repeating view.
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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
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.schoen...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
