Re: Executing AjaxEvent reset form inputs during Wicket test
Hard to tell, the code looks fine to me :/
Have fun
Sven
On 01.06.20 15:09, leodali83 wrote:
Hello Sven,
actually it helps a bit, some error feedback messages related to the 2 input
fields on which I set the value just after instantiation of FormTester
disappered.
Therefore, test fails again signaling the second dropdown (e.g.
"secondDropDownSelect") is required, which actually it is.
After instantiating again FormTester, code looks like this:
...
FormTester formTester =
wicketTester.newFormTester("detailsForm");
formTester.select("firstDropDownSelect", 0);
wicketTester.executeAjaxEvent("detailsForm:firstDropDownSelect",
"change");
formTester = wicketTester.newFormTester("detailsForm");
formTester.setValue("codice", "001");
formTester.setValue("matricola", "123456");
formTester.select("status", 0);
formTester.setValue("maxValoreTotalizzatore", "");
formTester.select("secondDropDownSelect", 0);
LocalDate tomorrow = LocalDate.now().plusDays(1);
String tomorrowAsString =
tomorrow.format(DateTimeFormatter.ofPattern("dd/MM/"));
formTester.setValue("scadenzaCertificatoMid:dateWrapper:date",
tomorrowAsString);
formTester.submit("save");
...
Sounds a bit strange. Is it losing again my request?
--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
-
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
Re: Locatable UnsupportedOperationException
https://issues.apache.org/jira/browse/WICKET-6796
On Mon, Jun 1, 2020 at 4:08 PM Sven Meier wrote:
> +1 that should have no negative impact
>
> Sven
>
> On 01.06.20 11:22, Martin Grigorov wrote:
> > Hi,
> >
> > I like the idea to catch UnsupportedOperationException at
> > org.apache.wicket.IGenericComponent#setModelObject(T) and re-throw it as:
> > throw new WicketRuntimeException("You need to use read/write Model for
> > component '{}", this.getPageRelativePath(), uox)
> >
> > Does anyone see a drawback ?
> >
> > Martin
> >
> > On Sat, May 30, 2020 at 11:42 PM Sven Meier wrote:
> >
> >> Hi,
> >>
> >> just put a breakpoint on IModel#setObject().
> >>
> >> Once your problem hits that breakpoint, you'll be able to derive the
> >> offending component/model from the stacktrace/variables in your favorite
> >> IDE.
> >>
> >> Have fun
> >> Sven
> >>
> >>
> >> On 30.05.20 17:13, smallufo wrote:
> >>> Is it possible to try { setObjectObject(value) } catch { e }
> >>> and pinpoint which class/model causes this problem ?
> >>> Or is it too costly ?
> >>>
> >>>
> >>> Francois Meillet 於 2020年5月30日 週六
> 下午11:02寫道：
> >>>
> Hope that help
>
> During the process of throwing an exception, the Java Virtual Machine
> abruptly completes, one by one, any expressions, statements, method
> and
> constructor invocations, initializers, and field initialization
> >> expressions
> that have begun but not completed execution in the current thread.
> This
> process continues until a handler is found that indicates that it
> >> handles
> that particular exception by naming the class of the exception or a
> superclass of the class of the exception (§11.2 <
>
> https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html#jls-11.2
> >>> ).
> If no such handler is found, then the exception may be handled by one
> >> of a
> hierarchy of uncaught exception handlers (§11.3 <
>
> https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html#jls-11.3
> >>> )
> - thus every effort is made to avoid letting an exception go
> unhandled.
>
> https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html <
> https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html>
>
>
> François
>
>
>
> > Le 30 mai 2020 à 16:52, smallufo a écrit :
> >
> > Francois Meillet 於 2020年5月30日 週六
> >> 下午10:48寫道：
> >> sompage?67-1.-border-content-border_body-form is the path to your
> >> model
> > Yes , but it may contains deep-nested model
> >
> > The form contains FormComponentPanel and contains another
> > FormComponentPanels and widgets , very deep ...
> > The error may lay under very deep model , which is very hard to
> debug.
> > And the error message should be able to pinpoint which model causes
> the
> > problem
> >> -
> >> 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
>
>
Re: Executing AjaxEvent reset form inputs during Wicket test
Hello Sven,
actually it helps a bit, some error feedback messages related to the 2 input
fields on which I set the value just after instantiation of FormTester
disappered.
Therefore, test fails again signaling the second dropdown (e.g.
"secondDropDownSelect") is required, which actually it is.
After instantiating again FormTester, code looks like this:
...
FormTester formTester =
wicketTester.newFormTester("detailsForm");
formTester.select("firstDropDownSelect", 0);
wicketTester.executeAjaxEvent("detailsForm:firstDropDownSelect",
"change");
formTester = wicketTester.newFormTester("detailsForm");
formTester.setValue("codice", "001");
formTester.setValue("matricola", "123456");
formTester.select("status", 0);
formTester.setValue("maxValoreTotalizzatore", "");
formTester.select("secondDropDownSelect", 0);
LocalDate tomorrow = LocalDate.now().plusDays(1);
String tomorrowAsString =
tomorrow.format(DateTimeFormatter.ofPattern("dd/MM/"));
formTester.setValue("scadenzaCertificatoMid:dateWrapper:date",
tomorrowAsString);
formTester.submit("save");
...
Sounds a bit strange. Is it losing again my request?
--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Locatable UnsupportedOperationException
+1 that should have no negative impact
Sven
On 01.06.20 11:22, Martin Grigorov wrote:
Hi,
I like the idea to catch UnsupportedOperationException at
org.apache.wicket.IGenericComponent#setModelObject(T) and re-throw it as:
throw new WicketRuntimeException("You need to use read/write Model for
component '{}", this.getPageRelativePath(), uox)
Does anyone see a drawback ?
Martin
On Sat, May 30, 2020 at 11:42 PM Sven Meier wrote:
Hi,
just put a breakpoint on IModel#setObject().
Once your problem hits that breakpoint, you'll be able to derive the
offending component/model from the stacktrace/variables in your favorite
IDE.
Have fun
Sven
On 30.05.20 17:13, smallufo wrote:
Is it possible to try { setObjectObject(value) } catch { e }
and pinpoint which class/model causes this problem ?
Or is it too costly ?
Francois Meillet 於 2020年5月30日 週六 下午11:02寫道：
Hope that help
During the process of throwing an exception, the Java Virtual Machine
abruptly completes, one by one, any expressions, statements, method and
constructor invocations, initializers, and field initialization
expressions
that have begun but not completed execution in the current thread. This
process continues until a handler is found that indicates that it
handles
that particular exception by naming the class of the exception or a
superclass of the class of the exception (§11.2 <
https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html#jls-11.2
).
If no such handler is found, then the exception may be handled by one
of a
hierarchy of uncaught exception handlers (§11.3 <
https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html#jls-11.3
)
- thus every effort is made to avoid letting an exception go unhandled.
https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html <
https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html>
François
Le 30 mai 2020 à 16:52, smallufo a écrit :
Francois Meillet 於 2020年5月30日 週六
下午10:48寫道：
sompage?67-1.-border-content-border_body-form is the path to your
model
Yes , but it may contains deep-nested model
The form contains FormComponentPanel and contains another
FormComponentPanels and widgets , very deep ...
The error may lay under very deep model , which is very hard to debug.
And the error message should be able to pinpoint which model causes the
problem
-
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
Re: Locatable UnsupportedOperationException
Hi,
I like the idea to catch UnsupportedOperationException at
org.apache.wicket.IGenericComponent#setModelObject(T) and re-throw it as:
throw new WicketRuntimeException("You need to use read/write Model for
component '{}", this.getPageRelativePath(), uox)
Does anyone see a drawback ?
Martin
On Sat, May 30, 2020 at 11:42 PM Sven Meier wrote:
> Hi,
>
> just put a breakpoint on IModel#setObject().
>
> Once your problem hits that breakpoint, you'll be able to derive the
> offending component/model from the stacktrace/variables in your favorite
> IDE.
>
> Have fun
> Sven
>
>
> On 30.05.20 17:13, smallufo wrote:
> > Is it possible to try { setObjectObject(value) } catch { e }
> > and pinpoint which class/model causes this problem ?
> > Or is it too costly ?
> >
> >
> > Francois Meillet 於 2020年5月30日 週六 下午11:02寫道：
> >
> >> Hope that help
> >>
> >> During the process of throwing an exception, the Java Virtual Machine
> >> abruptly completes, one by one, any expressions, statements, method and
> >> constructor invocations, initializers, and field initialization
> expressions
> >> that have begun but not completed execution in the current thread. This
> >> process continues until a handler is found that indicates that it
> handles
> >> that particular exception by naming the class of the exception or a
> >> superclass of the class of the exception (§11.2 <
> >> https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html#jls-11.2
> >).
> >> If no such handler is found, then the exception may be handled by one
> of a
> >> hierarchy of uncaught exception handlers (§11.3 <
> >> https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html#jls-11.3
> >)
> >> - thus every effort is made to avoid letting an exception go unhandled.
> >>
> >> https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html <
> >> https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html>
> >>
> >>
> >> François
> >>
> >>
> >>
> >>> Le 30 mai 2020 à 16:52, smallufo a écrit :
> >>>
> >>> Francois Meillet 於 2020年5月30日 週六
> 下午10:48寫道：
> >>>
> sompage?67-1.-border-content-border_body-form is the path to your
> model
>
> >>> Yes , but it may contains deep-nested model
> >>>
> >>> The form contains FormComponentPanel and contains another
> >>> FormComponentPanels and widgets , very deep ...
> >>> The error may lay under very deep model , which is very hard to debug.
> >>> And the error message should be able to pinpoint which model causes the
> >>> problem
> >>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Executing AjaxEvent reset form inputs during Wicket test
Hi,
you have to use a new FormTester instance after executing the Ajax event:
...
formTester = tester.newFormTester(path)
formTester.select("field1", ""); // required field
formTester.select("field2", ""); // required field
.
formTester.select("firstDropDownSelect", 0);
wicketTester.executeAjaxEvent("detailsForm:firstDropDownSelect","change");
formTester.select("secondDropDownSelect", 0);
formTester = tester.newFormTester(path);
formTester.submit()
...
Executing a request (e.g. via executeAjaxEvent) 'consumes' the current
request and WicketTester sets up a new 'empty' request.
A new FormTester will fill the parameters of that new request with the
current state of your components.
Hope this helps
Sven
Hi,
you have to use a new FormTester instance after executing the Ajax event:
...
formTester = tester.newFormTester(path)
formTester.select("field1", ""); // required field
formTester.select("field2", ""); // required field
.
formTester.select("firstDropDownSelect", 0);
wicketTester.executeAjaxEvent("detailsForm:firstDropDownSelect","change");
formTester.select("secondDropDownSelect", 0);
formTester = tester.newFormTester(path)
formTester.submit()
...
Executing a request (e.g. via executeAjaxEvent) 'consumes' the current
request and a new one is set up by WicketTester.
Otherwise the values of the form
On 01.06.20 09:59, leodali83 wrote:
Hello everybody,
I'm developing a web application built on Wicket 8.
Now i'm testing a form containing 2 DropDownChoice, the selection of the
first one should refresh elements to be choose on the second through the
Ajax "change" event.
When i submit my form and I test feedback messages displayed during the
process, the form seems to have lost all the other field setted before the 2
drop downs below:
...
formTester.select("field1", ""); // required field
formTester.select("field2", ""); // required field
.
formTester.select("firstDropDownSelect", 0);
wicketTester.executeAjaxEvent("detailsForm:firstDropDownSelect",
"change");
formTester.select("secondDropDownSelect", 0);
...
The Wicket Tester fails the test stating "field1" and "field2" are required
fields, although I setted it correctly... :/
If I try the same behaviour interactively, it works fine.
What am I missing from my test?
Thanks in advance for any suggestions,
Leonardo
--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
-
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
Executing AjaxEvent reset form inputs during Wicket test
Hello everybody,
I'm developing a web application built on Wicket 8.
Now i'm testing a form containing 2 DropDownChoice, the selection of the
first one should refresh elements to be choose on the second through the
Ajax "change" event.
When i submit my form and I test feedback messages displayed during the
process, the form seems to have lost all the other field setted before the 2
drop downs below:
...
formTester.select("field1", ""); // required field
formTester.select("field2", ""); // required field
.
formTester.select("firstDropDownSelect", 0);
wicketTester.executeAjaxEvent("detailsForm:firstDropDownSelect",
"change");
formTester.select("secondDropDownSelect", 0);
...
The Wicket Tester fails the test stating "field1" and "field2" are required
fields, although I setted it correctly... :/
If I try the same behaviour interactively, it works fine.
What am I missing from my test?
Thanks in advance for any suggestions,
Leonardo
--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
