Dear Martin,
W dniu 2017-08-20 o 22:50, Martin Grigorov pisze:
Dear Kamil,
On Sat, Aug 19, 2017 at 7:26 PM, Kamil Paśko <kamil.pa...@solsoft.pl> wrote:
Dear Wicket Devs,
I'd like to ask you for starting a discussion about unifying how "click"
and "submit" are handled in WicketTester/FormTester.
Facts:
*1) clickLink and Buttons*
Currently WicketTester has "#clickLink" method. Its javadoc says:
/"When clicking an AjaxSubmitLink the form, which the AjaxSubmitLink is
attached to is first submitted, and then the onSubmit method on
AjaxSubmitLink is invoked. If you have changed some values in the form
during your test, these will also be submitted. This should not be used as
a replacement for the {@link FormTester} to test your forms. It should be
used to test that the code in your onSubmit method in AjaxSubmitLink
actually works."/
As I stated in https://issues.apache.org/jira/browse/WICKET-6442 it
possibly could work also for SubmitButton, but as Martin Grigorov rightly
noticed:
/"clickLink should not deal with Buttons."/
And also:
/"clickLink() is there since early versions and it is hard to remove it
now. We don't want #clickButton(), #submitButton(), #blurButton(),
#hoverLabel(), etc."/
*
*
*2) checkboxes*
Checkboxes are not only used in forms. AjaxCheckbox often serves as
"Enable/Disable" or "Show/Hide" trigger.
It is "logical" that if I *click* checkbox - its action is invoked. Right?
Unfortunately not. It occurs that first I must "set it to true" (
https://issues.apache.org/jira/browse/WICKET-6447)
It's not the way users interact with application and in my opinion it
shouldn't be tested that way because it's cumbersome and away from reality.
*
*
*3) **submitting forms*
It occurs that FormTester #submit method works in a strange way (it
submits form without "submit button", but doesn't submit anything if it has
default button https://issues.apache.org/jira/browse/WICKET-6446) which
seem weird to me.
As Sven Meier noticed:
/There are thousands of tests out there, we won't break these by changing
the semantics of a method.//
//Feel free to submit a pull request that adds a new method to FormTester,
e.g. #submitDefaultButton()/
But I don't think that another submit method (remember that
BaseWicketTester already has two: #submitForm(Form<?>) and
#submitForm(String) ) is what you want (recall what Martin Grigorov said)
*Sum up:*
1) What do you think about single "clickIt" method that you can use to
click on a link/button or checkbox?
1) What should be the behavior of: 1) click(checkbox) + click(checkbox) +
submit(form) ?
In your simpler world it sounds like it should just set the checkbox' value
to true and submit the form.
But in a real browser it will select it, then deselect it and submit
nothing for it.
So it is not so simple as you describe it. it will have to be smarter and
keep the state until being submitted.
But it is doable!
I assumed, that for explicitly testing forms (hence selecting explicit
value of checkbox for form submission) we should use of course FormTester.
Here I'm only talking about checkboxes that are "functional" (I don't
know how to call it properly - the ones that are changing state,
enabling/disabling something etc.)
An example:
final Panel hides = new Panel("hides") {
@Override
protected void onConfigure() {
super.onConfigure();
setVisible(model.getObject());
}
};
final AjaxCheckBox functional = new AjaxCheckBox("targeted", model) {
protected void onUpdate(AjaxRequestTarget target) {
target.add(hides);
}
};
But yes, click + click should leave the same model value as 0 clicks
2) What do you think about submit method , which can submit form without
any submit button or with the default one?
As proposed by Sven and seconded by me: please work on it and send a Pull
Request / attach a patch !
I still doesn't understand why submit() can not do both.
Clearly I have less knowledge than you, so please explain me the reasons.
3) Wicket8 is going to be released soon and I think that it's perfect
occasion, to clean the API and even break compatibility (when necessary)
for the sake of better API
*When is better time than now to straighten this up?*
Everyone says that and we will never release it this way :-/
I am asking to release 8.0.0 since half an year but we postpone it for one
reason or another.
I will not stand in your (or anyone else's) way to add these new features
and provide better APIs but I don't feel inclined to help either.
If I see something that feels wrong I will raise my voice! As for the
disabling the IndicatingAjaxButton by default.
IMHO all of these proposals can be done in a minor release too. I don't see
any API break proposal in them. If some old API should be removed it should
stay in 8.x as deprecated anyway.
Ok, you're right.
Could you at least help me to come up with one consistent solution (that
you agree with), so we can start with it?
Kind regards,
Kamil
