[jira] [Commented] (WICKET-5552) Events to close pop-up on Modal Window are not propagated
[
https://issues.apache.org/jira/browse/WICKET-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645740#comment-16645740
]
ASF GitHub Bot commented on WICKET-5552:
Github user andruhon commented on the issue:
https://github.com/apache/wicket/pull/294
@svenmeier sure, it was the first thing I tried. Unfortunately it prevents
the w_captionText of the popup from working as a drag area, which I think is
undesired effect.
Potentially can be done as something like `e.target !== this &&
e.target.className.indexOf('w_captionText') == -1`, but it makes the
mouseDownHandler know about css classes of modal so I think the approach with
some general stopper class is more universal.
> Events to close pop-up on Modal Window are not propagated
> -
>
> Key: WICKET-5552
> URL: https://issues.apache.org/jira/browse/WICKET-5552
> Project: Wicket
> Issue Type: Bug
> Components: wicket-extensions
>Affects Versions: 6.14.0
> Environment: Windows/Eclipse/JRE7
>Reporter: Neil Bennett
>Priority: Major
> Labels: javascript, modalwindow
> Attachments: quickstart.zip
>
>
> When using a field on a modal window that shows a pop-up window, like a time
> picker, when clicking outside of the pop-up window but over the modal window,
> mousedown/click events are not propagated. Clicks outside of the modal window
> are propagated.
> This is due to Wicket.Event.stop(event) being called on mousedown on the
> w_content_1 component. Removal of this leads to the Drag javascript being
> executed which itself calls Wicket.Event.stop(event), disabling this then
> propagates the event which leads to the pop-up window being closed but causes
> any field on the modalwindow to get focus.
> I have a quickstart that demonstrates the modalwindow behavior vs that on a
> page. You will see that launching the modal window and clicking on the time
> component opens the pop-up window. However, you can only get this to close
> when clicking outside of the modal window. The same component has been put on
> the main page as a comparison which does close when clicking outside of the
> pop-up window.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (WICKET-5552) Events to close pop-up on Modal Window are not propagated
[
https://issues.apache.org/jira/browse/WICKET-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645346#comment-16645346
]
ASF GitHub Bot commented on WICKET-5552:
Github user svenmeier commented on the issue:
https://github.com/apache/wicket/pull/294
Why so complicated - I've fixed the issue by removing the mouse blocker
from modal.js and restricting any dragging on the element itself:
```
diff --git
a/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js
b/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js
index 64852de..8d94b36 100644
---
a/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js
+++
b/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js
@@ -2485,6 +2485,10 @@
mouseDownHandler: function (e) {
e = Wicket.Event.fix(e);
+
+ if (e.target !== this) {
+ return;
+ }
var element = this;
diff --git
a/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/res/modal.js
b/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/res/modal.js
index f683119..5a0f122 100644
---
a/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/res/modal.js
+++
b/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/res/modal.js
@@ -1189,7 +1189,7 @@
""+
""+
""+
- ""+
+ ""+
""+
""+
""+
```
Can you try that instead?
> Events to close pop-up on Modal Window are not propagated
> -
>
> Key: WICKET-5552
> URL: https://issues.apache.org/jira/browse/WICKET-5552
> Project: Wicket
> Issue Type: Bug
> Components: wicket-extensions
>Affects Versions: 6.14.0
> Environment: Windows/Eclipse/JRE7
>Reporter: Neil Bennett
>Priority: Major
> Labels: javascript, modalwindow
> Attachments: quickstart.zip
>
>
> When using a field on a modal window that shows a pop-up window, like a time
> picker, when clicking outside of the pop-up window but over the modal window,
> mousedown/click events are not propagated. Clicks outside of the modal window
> are propagated.
> This is due to Wicket.Event.stop(event) being called on mousedown on the
> w_content_1 component. Removal of this leads to the Drag javascript being
> executed which itself calls Wicket.Event.stop(event), disabling this then
> propagates the event which leads to the pop-up window being closed but causes
> any field on the modalwindow to get focus.
> I have a quickstart that demonstrates the modalwindow behavior vs that on a
> page. You will see that launching the modal window and clicking on the time
> component opens the pop-up window. However, you can only get this to close
> when clicking outside of the modal window. The same component has been put on
> the main page as a comparison which does close when clicking outside of the
> pop-up window.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (WICKET-6597) Automatic Component/FormComponents based on java.lang.reflect.Field.type, extensible also to links and buttons
[ https://issues.apache.org/jira/browse/WICKET-6597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Grigorov resolved WICKET-6597. - Resolution: Won't Do No one shared an opinion on this but I think it should grow as a third party library first and eventually moved to wicket-core if it proves itself. > Automatic Component/FormComponents based on java.lang.reflect.Field.type, > extensible also to links and buttons > -- > > Key: WICKET-6597 > URL: https://issues.apache.org/jira/browse/WICKET-6597 > Project: Wicket > Issue Type: Improvement > Components: wicket-core >Reporter: Martin Terra >Priority: Minor > > We propose that Wicket would have the capability to instantiate type-specific > FormComponents (CheckBox, DropDownChoice, etc.) automatically in a somewhat > similar way that it now automatically handles type conversions (components > such as Labels, Links, and Buttons to be generated also with suitable > parametrization). It automatically also generates markup based on a template > (input, select, link, button, label, etc. have somewhat different markup and > there can be a custom standard structure like prefixes and suffixes etc.). > There would be a default out-of-the-box mapping which user can override as > necessary. The components are instantiated in a way that gives the components > access to the context in which they are in, for example a model instantiator > can access other components in the same context or an ajax event can access > other components as necessary. > > We have madea a custom implementation for this in our project using a > component factory (we can maybe post here later as it gets more refined, > whichever comes first). The benefits of this approach is that we can make a > "defined-once-used-many-times" definition of an api (validation rules, > component interdependencies, authorization) by listing properties user is > allowed to interact with in a static manner, and using the same definition to > generate both wicket ui and rest api. For example. Furthermore, it encourages > best practices html/css layout generation when all components are generated > in a standard way (for example, each FormComponent is automatically > accompanied by a Label). We can make a static definition for a View and its > contents could be Sections which contain Tables, Labels or FormComponents > that are defined in a generic "table of contents" which is used to generate > the ui. The "table of contents" can also be used for search based on either > data values or field label (or even tooltip) properties. > > Something similar (but maybe not as generic) has been discussed way back in > thread > [http://apache-wicket.1842946.n4.nabble.com/Component-Factory-and-code-against-interface-td1846370.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
