[jira] Updated: (WICKET-1902) Javascript error multiple click on closing modalwindow
[ https://issues.apache.org/jira/browse/WICKET-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-1902: -- Fix Version/s: (was: 1.3.4) > Javascript error multiple click on closing modalwindow > -- > > Key: WICKET-1902 > URL: https://issues.apache.org/jira/browse/WICKET-1902 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.3.4 > Environment: Internet Explorer >Reporter: Frank Klein Koerkamp >Assignee: Matej Knopp > Original Estimate: 0.17h > Remaining Estimate: 0.17h > > When I multiple click on the closing button of the modalwindow i get js error. > On the line win.current.close();. Because window.current == null. > Maybe an extra check? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1920) Settings mounts as case insensitive causes 404 errors if case is included when mounting pages.
Settings mounts as case insensitive causes 404 errors if case is included when
mounting pages.
--
Key: WICKET-1920
URL: https://issues.apache.org/jira/browse/WICKET-1920
Project: Wicket
Issue Type: Bug
Components: wicket
Environment: Windows XP, Java 1.6, Wicket 1.4-SNAPSHOT revision 712226
Reporter: Matthew R Hanlon
Priority: Minor
Attachments: MountsBugTestCase.tar.bz2
Settings mounts as case insensitive causes 404 errors if case is included when
mounting pages.
Example:
public class MyApplication extends WebApplication {
...
@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new WebRequestCycleProcessor() {
@Override
protected IRequestCodingStrategy newRequestCodingStrategy() {
WebRequestCodingStrategy.Settings strategySettings = new
WebRequestCodingStrategy.Settings();
strategySettings.setMountsCaseSensitive(false);
return new WebRequestCodingStrategy(strategySettings);
}
};
}
...
@Override
public void init() {
...
mountBookmarkablePage("/mypage1", MyPage1.class); // works
mountBookmarkablePage("/myPage2", MyPage2.class); // causes 404
...
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1920) Settings mounts as case insensitive causes 404 errors if case is included when mounting pages.
[
https://issues.apache.org/jira/browse/WICKET-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew R Hanlon updated WICKET-1920:
-
Attachment: MountsBugTestCase.tar.bz2
QuickStart test case that reproduces this problem.
> Settings mounts as case insensitive causes 404 errors if case is included
> when mounting pages.
> --
>
> Key: WICKET-1920
> URL: https://issues.apache.org/jira/browse/WICKET-1920
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Environment: Windows XP, Java 1.6, Wicket 1.4-SNAPSHOT revision 712226
>Reporter: Matthew R Hanlon
>Priority: Minor
> Attachments: MountsBugTestCase.tar.bz2
>
>
> Settings mounts as case insensitive causes 404 errors if case is included
> when mounting pages.
> Example:
> public class MyApplication extends WebApplication {
>...
>@Override
>protected IRequestCycleProcessor newRequestCycleProcessor() {
> return new WebRequestCycleProcessor() {
> @Override
> protected IRequestCodingStrategy newRequestCodingStrategy() {
> WebRequestCodingStrategy.Settings strategySettings = new
> WebRequestCodingStrategy.Settings();
> strategySettings.setMountsCaseSensitive(false);
> return new WebRequestCodingStrategy(strategySettings);
> }
> };
>}
>...
>@Override
>public void init() {
>...
>mountBookmarkablePage("/mypage1", MyPage1.class); // works
>mountBookmarkablePage("/myPage2", MyPage2.class); // causes 404
>...
>}
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-713) AbstractAjaxBehavior can not be reused.
[
https://issues.apache.org/jira/browse/WICKET-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Borges updated WICKET-713:
Attachment: patch-713.diff
Patch attached.
It adds an unbind method to IBehavior, fix AbstractBehavior and of course
AjaxAbstractBehavior, cleaning up the referenced component.
cheers,
Bruno
> AbstractAjaxBehavior can not be reused.
> ---
>
> Key: WICKET-713
> URL: https://issues.apache.org/jira/browse/WICKET-713
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Reporter: Martin Funk
> Fix For: 1.5-M1
>
> Attachments: patch-713.diff
>
>
> AbstractAjaxBehavior is receiving a Component upon bind, this is keept even
> when the Behavior is removed from the Component
> so if the Behavior is added again it throws a
> IllegalStateException("this kind of handler
> cannot be attached to "
> + "multiple components; it is already
> attached to component " + this.component
> + ", but component " + hostComponent +
> " wants to be attached too");
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1858) IE 6 image caching: performance issue during ajax updates
[ https://issues.apache.org/jira/browse/WICKET-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Derugo updated WICKET-1858: -- Description: Steps to reproduce: 1. Create table(let's say 50 rows) using any repeater. 2. Add AjaxButton to each row, for example: - when user clicks on this button - the application also refreshes the entire table. - Result: Since IE cannot cache images during AJAX updates it will take more time to re-load all images. See details here http://www.bazon.net/mishoo/articles.epl?art_id=958 Ajax AjaxRequestTarget turns off caching (i.e. sets header "Cache-Control" to "no-cache") as the result the browser must send many requests to the server. Workaround: Create Filter that will override the caching *only* for images, for example: if URL matches *.gif then the filter will set Cache-Control : public,max-age=2592000,post-check=2592000,pre-check=2592000. This solution noticeably improves performance Possible solution: Wicket shouldn't override caching settings for images (*.gif, *.png etc.) was: Steps to reproduce: 1. Create table(let's say 50 rows) using any repeater. 2. Add AjaxButton to each row, for example: - when user clicks on this button - the application also refreshes the entire table. - Result: Since IE cannot cache images during AJAX updates it will take more time to re-load all images. See details here http://www.bazon.net/mishoo/articles.epl?art_id=958 Ajax AjaxRequestTarget turns off caching (i.e. sets header "Cache-Control" to "no-cache") as the result the browser must send many requests to the server. Workaround: Create Filter that will override the caching *only* for images, for example: if URL matches *.gif then the filter will set Cache-Control : public,max-age=2592000,post-check=2592000,pre-check=2592000. This solution noticably improves performance Possible solution: Wicket shouldn't override caching settings for images (*.gif, *.png etc.) > IE 6 image caching: performance issue during ajax updates > - > > Key: WICKET-1858 > URL: https://issues.apache.org/jira/browse/WICKET-1858 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-M3 > Environment: IE 6 >Reporter: Sergey Derugo >Priority: Critical > > Steps to reproduce: > 1. Create table(let's say 50 rows) using any repeater. > 2. Add AjaxButton to each row, for example: wicket:id="editButton" alt="Edit"/> - when user clicks on this button - the > application also refreshes the entire table. > - > Result: Since IE cannot cache images during AJAX updates it will take more > time to re-load all images. See details here > http://www.bazon.net/mishoo/articles.epl?art_id=958 > Ajax AjaxRequestTarget turns off caching (i.e. sets header "Cache-Control" to > "no-cache") as the result the browser must send many requests to the server. > Workaround: > Create Filter that will override the caching *only* for images, for example: > if URL matches *.gif then the filter will set Cache-Control : > public,max-age=2592000,post-check=2592000,pre-check=2592000. This solution > noticeably improves performance > Possible solution: > Wicket shouldn't override caching settings for images (*.gif, *.png etc.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1919) MarkupContainer.setEnabled() doesn't enable/disable child components
[
https://issues.apache.org/jira/browse/WICKET-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Derugo closed WICKET-1919.
-
Accepted
> MarkupContainer.setEnabled() doesn't enable/disable child components
>
>
> Key: WICKET-1919
> URL: https://issues.apache.org/jira/browse/WICKET-1919
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.3, 1.4-M3
>Reporter: Sergey Derugo
>Assignee: Igor Vaynberg
> Fix For: 1.4-RC2
>
> Attachments: src.zip
>
>
> 1. Create any components that is derived from MarkupContainer, for example,
> create Panel.
> 2. Put some components to the Panel, for example, TextInput, Label etc.
> 3. Call panel.setEnabled(false)
> Result: all controls on panel are still enabled.
> Notes: after some investigation I found that MarkupContainer doesn't override
> setEnabled and therefore it cannot enable/disable components stored in the
> container.
> Workaround: manually disable all components that are displayed on the panel,
> for example:
> public void setEnabledForChildren(boolean enabled) {
> setEnabledRecursive(this, enabled);
> }
> private void setEnabledRecursive(MarkupContainer container, boolean
> enabled) {
> Iterator iterator = container.iterator();
> while (iterator.hasNext()) {
> Component component = iterator.next();
> component.setEnabled(enabled);
> if (component instanceof MarkupContainer) {
> setEnabledRecursive((MarkupContainer) component, enabled);
> }
> }
> }
> I think that MarkupContainer must be responsible for disabling/enabling child
> components.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1916) setResponsePage(Application#getHomePage()) mounted as / (default) vs. ajax requests
[ https://issues.apache.org/jira/browse/WICKET-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645733#action_12645733 ] Jan Loose commented on WICKET-1916: --- The compilation works fine now:-) But the AJAX bug is still there:-( > setResponsePage(Application#getHomePage()) mounted as / (default) vs. ajax > requests > --- > > Key: WICKET-1916 > URL: https://issues.apache.org/jira/browse/WICKET-1916 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-M3 >Reporter: Jan Loose >Assignee: Martijn Dashorst > > Hi, > I'm using a week old version of wicket 1.4-SNAPSHOT and there is one ugly bug > ... in ajax request cannot be send redirect to homepage ... > setResponsePage(Application#getHomePage()) because there is return onlu one > byte as the response a in Ajax Debug Console I see this: > --- > INFO: Using XMLHttpRequest transport > INFO: > INFO: Initiating Ajax POST request on > ?wicket:interface=:3:loginSwitchPanel:loginPanel:form:submit::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.03614674718119204 > INFO: Invoking pre-call handler(s)... > INFO: Received ajax response (1 characters) > INFO: > > ERROR: Error while parsing response: Could not find root > element > INFO: Invoking post-call handler(s)... > INFO: Invoking failure handler(s)... > --- > If I mount the homepage to for example /home then is all ok. > I can try to compile last trunk version of wicket 1.4-SNAPSHOT but there is 7 > failed tests: > Failed tests: > > testAjaxHeaderContribution(org.apache.wicket.ajax.AjaxHeaderContributionTest) > > testDoubleAjaxHeaderContribution(org.apache.wicket.ajax.AjaxHeaderContributionTest) > > testBufferedExceptionErrorPage(org.apache.wicket.protocol.http.WebResponseExceptionsTest) > > testExceptionErrorPage(org.apache.wicket.protocol.http.WebResponseExceptionsTest) > testExpirePage(org.apache.wicket.protocol.http.WebResponseExceptionsTest) > > testInternalErrorPage(org.apache.wicket.protocol.http.WebResponseExceptionsTest) > testDomReadyOrder(org.apache.wicket.ajax.DomReadyOrderTest) > Tests run: 722, Failures: 7, Errors: 0, Skipped: 0 > --- > Thx for help! > H. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
