Add IFallback marker interface to AjaxFallback* components
The WicketTester has a click method that doesn't detect all AJAX capable links (e.g. the Ajax links in the AjaxPagingNavigator are not testable). When trying to fix this by adding support for IAjaxLink, I noticed that we also don't support AjaxFallbackButton, and probably a lot more components. Should we introduce a marker interface for fallback components? (or should we wait until Optional support arrives with Java 8 in Wicket 8) Martijn
Re: Add IFallback marker interface to AjaxFallback* components
I would prefer the interface because Wicket 6 / 7 users should also see that components are not supported. kind regards Tobias Am 06.05.2015 um 11:03 schrieb Martijn Dashorst martijn.dasho...@gmail.com: The WicketTester has a click method that doesn't detect all AJAX capable links (e.g. the Ajax links in the AjaxPagingNavigator are not testable). When trying to fix this by adding support for IAjaxLink, I noticed that we also don't support AjaxFallbackButton, and probably a lot more components. Should we introduce a marker interface for fallback components? (or should we wait until Optional support arrives with Java 8 in Wicket 8) Martijn
Re: Add IFallback marker interface to AjaxFallback* components
On May 6, 2015 3:10 PM, Martijn Dashorst martijn.dasho...@gmail.com
wrote:
On Wed, May 6, 2015 at 1:35 PM, Martin Grigorov mgrigo...@apache.org
wrote:
+1 to introduce IFallback
I don't understand how Optional could help for this use case
Change the onClick signature (perhaps only for Ajax fallback components):
public void onClick(OptionalAjaxRequestTarget target) {
}
This expresses clearly that target is optional, and hence that a
fallback scenario is possible.
Yeah, but how this could be exploited in WicketTester?
Martijn
On Wed, May 6, 2015 at 12:03 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
The WicketTester has a click method that doesn't detect all AJAX
capable links (e.g. the Ajax links in the AjaxPagingNavigator are not
testable).
When trying to fix this by adding support for IAjaxLink, I noticed
that we also don't support AjaxFallbackButton, and probably a lot more
components.
Should we introduce a marker interface for fallback components?
(or should we wait until Optional support arrives with Java 8 in
Wicket 8)
Martijn
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: wicket git commit: Added WicketTester support for IAjaxLink
Hi,
On Wed, May 6, 2015 at 12:25 PM, dasho...@apache.org wrote:
Repository: wicket
Updated Branches:
refs/heads/wicket-6.x e4c1d939f - 0199bfab7
Added WicketTester support for IAjaxLink
WicketTester didn't click direct IAjaxLink implementations using an
Ajax request but a normal request. Some components implement
IAjaxLink directly instead of subclassing AjaxLink or other
components.
Fixes WICKET-5900
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/0199bfab
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/0199bfab
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/0199bfab
Branch: refs/heads/wicket-6.x
Commit: 0199bfab7cc27e14759d634a1b48f92c9e59a9d2
Parents: e4c1d93
Author: Martijn Dashorst martijn.dasho...@gmail.com
Authored: Wed May 6 11:22:55 2015 +0200
Committer: Martijn Dashorst martijn.dasho...@gmail.com
Committed: Wed May 6 11:25:22 2015 +0200
--
.../org/apache/wicket/util/tester/BaseWicketTester.java | 11 +++
1 file changed, 11 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/wicket/blob/0199bfab/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
--
diff --git
a/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
b/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
index 2849c3c..8b230b8 100644
---
a/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
+++
b/wicket-core/src/main/java/org/apache/wicket/util/tester/BaseWicketTester.java
@@ -59,6 +59,7 @@ import org.apache.wicket.ajax.AjaxEventBehavior;
import org.apache.wicket.ajax.form.AjaxFormSubmitBehavior;
import org.apache.wicket.ajax.markup.html.AjaxFallbackLink;
import org.apache.wicket.ajax.markup.html.AjaxLink;
+import org.apache.wicket.ajax.markup.html.IAjaxLink;
import org.apache.wicket.ajax.markup.html.form.AjaxSubmitLink;
import org.apache.wicket.behavior.AbstractAjaxBehavior;
import
org.apache.wicket.core.request.handler.BookmarkablePageRequestHandler;
@@ -1881,6 +1882,16 @@ public class BaseWicketTester
submitAjaxFormSubmitBehavior(link,
(AjaxFormSubmitBehavior)WicketTesterHelper.findAjaxEventBehavior(link,
onclick));
}
+ // if the link is an IAjaxLink, use it (do check if AJAX
is expected)
+ else if (linkComponent instanceof IAjaxLink isAjax)
I see some inconsistencies now:
1) earlier there is a check for AjaxLink that is also IAjaxLink and it has
the same logic
2) it uses fail() in the case when isAjax is false
IMO AjaxPagingNavigationLink should behave the same way. In the browser it
would not act as a **Fallback link
Maybe the code for AjaxLink and IAjaxLink should be merged?!
Additionally we can introduce IFallback marker interface (as you suggested
at dev@) and fail if isAjax is false isFallback == false.
+ {
+ ListAjaxEventBehavior behaviors =
WicketTesterHelper.findAjaxEventBehaviors(
+ linkComponent, click);
+ for (AjaxEventBehavior behavior : behaviors)
+ {
+ executeBehavior(behavior);
+ }
+ }
/*
* If the link is a submitlink then we pretend to have
clicked it
*/
Re: Add IFallback marker interface to AjaxFallback* components
On Wed, May 6, 2015 at 1:35 PM, Martin Grigorov mgrigo...@apache.org wrote:
+1 to introduce IFallback
I don't understand how Optional could help for this use case
Change the onClick signature (perhaps only for Ajax fallback components):
public void onClick(OptionalAjaxRequestTarget target) {
}
This expresses clearly that target is optional, and hence that a
fallback scenario is possible.
Martijn
On Wed, May 6, 2015 at 12:03 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
The WicketTester has a click method that doesn't detect all AJAX
capable links (e.g. the Ajax links in the AjaxPagingNavigator are not
testable).
When trying to fix this by adding support for IAjaxLink, I noticed
that we also don't support AjaxFallbackButton, and probably a lot more
components.
Should we introduce a marker interface for fallback components?
(or should we wait until Optional support arrives with Java 8 in Wicket 8)
Martijn
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Migration to 7 report
On Mon, May 4, 2015 at 9:26 PM, Martin Grigorov mgrigo...@apache.org wrote: What's wrong with 'instanceof'+casting? Nothing, except it's more verbose. I'll go do that. I was wondering if it might be worth it to add a way to define the error keys with a setter of PatternValidator. We usually override the message to make it understandable by the user (a regexp doesn't qualify as understandable for most users). Are we the only ones? If it's of some interest, I can prepare a PR for that. -- Guillaume
Re: Add IFallback marker interface to AjaxFallback* components
+1 to introduce IFallback I don't understand how Optional could help for this use case On Wed, May 6, 2015 at 12:03 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: The WicketTester has a click method that doesn't detect all AJAX capable links (e.g. the Ajax links in the AjaxPagingNavigator are not testable). When trying to fix this by adding support for IAjaxLink, I noticed that we also don't support AjaxFallbackButton, and probably a lot more components. Should we introduce a marker interface for fallback components? (or should we wait until Optional support arrives with Java 8 in Wicket 8) Martijn
[wicketstuff] Can't we get rid of the distinction between JDK-versions on the folder level?
Hi, As I already mentioned the other day I was porting some changes from master branch to the wicket-6.x branch (http://apache-wicket.1842946.n4.nabble.com/wicketstuff-Need-help-with-cherry-picking-td4670615.html) and had some trouble doing so, since Git was not able to cherry-pick my changes due to a different folder structure. Since this was really a pain in the neck (and quite erroneous) I would like to know if we cannot get rid of the distinction between different JDK versions in the folder structure. At the moment all projects on the master branch are located in the jdk-1.7-parent folder (since no project requires Java 8 yet, the jdk-1.8-parent folder is empty). Most of those projects reside in the jdk-1.6-parent folder on the wicket-6.x branch, making it impossible to simply downport changes via cherry-picking. Only difference between the POMs in those folders are the source- and target-level for the Maven compiler plugin. Can't we just put everything in one folder and override source- and target-level in the project specific POM if a project needs a higher version than the default one? The only drawback I see at the moment is the fact, that you cannot recognize at a first glance if a project needs a higher Java version. Or do I overlook here something? To be honest: I don't know if I would downport bigger changes on a project when myself only needs those changes on the master branch (since I'm already using Wicket 1.7) and downporting is such a hassle. Joachim
