[jira] Commented: (WICKET-2431) Some live demo examples don't work
[
https://issues.apache.org/jira/browse/WICKET-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750324#action_12750324
]
Sergey Derugo commented on WICKET-2431:
---
{quote}i think the examples need to be redeployed with 1.3.7{quote}
Are you going to fix the examples for the version 1.4?
Some live demo examples don't work
--
Key: WICKET-2431
URL: https://issues.apache.org/jira/browse/WICKET-2431
Project: Wicket
Issue Type: Bug
Affects Versions: 1.4.0
Environment: http://www.wicketstuff.org/wicket13/repeater/
Reporter: Sergey Derugo
Assignee: Johan Compagner
Steps to reproduce:
1. Go to http://www.wicketstuff.org/wicket13/repeater/
2. Click to one of the following links
OrderedRepeatingView Example - basic example of a repeater view
RefreshingView Example - basic view that recreates its items every request
Contacts Editor - based on the previous example, but with editable values
Result: Internal error occurs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2431) Some live demo examples don't work
Some live demo examples don't work -- Key: WICKET-2431 URL: https://issues.apache.org/jira/browse/WICKET-2431 Project: Wicket Issue Type: Bug Affects Versions: 1.4.0 Environment: http://www.wicketstuff.org/wicket13/repeater/ Reporter: Sergey Derugo Steps to reproduce: 1. Go to http://www.wicketstuff.org/wicket13/repeater/ 2. Click to one of the following links OrderedRepeatingView Example - basic example of a repeater view RefreshingView Example - basic view that recreates its items every request Contacts Editor - based on the previous example, but with editable values Result: Internal error occurs. -- 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? extends Component 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] 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: img src=../images/edit.gif 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.) was: Steps to reproduce: 1. Create table(let's say 50 rows) using any repeater. 2. Add AjaxButton to each row, for example: img src=../images/edit.gif 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 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: img src=../images/edit.gif 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] Created: (WICKET-1919) MarkupContainer.setEnabled() doesn't enable/disable child components
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.4-M3, 1.3.3
Reporter: Sergey Derugo
Fix For: 1.4-RC2
# Create any components that is derived from MarkupContainer, for example,
create Panel.
# Put some components to the Panel, for example, TextInput, Label etc.
# Call panel.setEnabled(false)
Result: all controls on panel are still disabled.
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? extends Component 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] Updated: (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 updated WICKET-1919:
--
Description:
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 disabled.
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? extends Component 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.
was:
# Create any components that is derived from MarkupContainer, for example,
create Panel.
# Put some components to the Panel, for example, TextInput, Label etc.
# Call panel.setEnabled(false)
Result: all controls on panel are still disabled.
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? extends Component 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.
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
Fix For: 1.4-RC2
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 disabled.
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? extends Component 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] Updated: (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 updated WICKET-1919:
--
Description:
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? extends Component 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.
was:
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 disabled.
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? extends Component 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.
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
Fix For: 1.4-RC2
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? extends Component 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] Updated: (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 updated WICKET-1919:
--
Attachment: PanelTestPage.html
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
Fix For: 1.4-RC2
Attachments: MyPanel.html, MyPanel.java, PanelTestPage.html
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? extends Component 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] Updated: (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 updated WICKET-1919:
--
Attachment: MyPanel.java
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
Fix For: 1.4-RC2
Attachments: MyPanel.html, MyPanel.java, PanelTestPage.html
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? extends Component 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] Updated: (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 updated WICKET-1919:
--
Attachment: MyPanel.html
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
Fix For: 1.4-RC2
Attachments: MyPanel.html, MyPanel.java, PanelTestPage.html
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? extends Component 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] Updated: (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 updated WICKET-1919:
--
Attachment: (was: MyPanel.html)
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
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? extends Component 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] Issue Comment Edited: (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:comment-tabpanelfocusedCommentId=12645487#action_12645487
]
xsergey edited comment on WICKET-1919 at 11/6/08 7:02 AM:
In the attachment(src.zip) you can find simple test case
was (Author: xsergey):
In the attachment [^src.zip] you can find simple test case
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
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? extends Component 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-1919) MarkupContainer.setEnabled() doesn't enable/disable child components
[
https://issues.apache.org/jira/browse/WICKET-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12645487#action_12645487
]
Sergey Derugo commented on WICKET-1919:
---
In the attachment [^src.zip] you can find simple test case
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
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? extends Component 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] Updated: (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 updated WICKET-1919:
--
Attachment: src.zip
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
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? extends Component 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] Updated: (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 updated WICKET-1919:
--
Attachment: (was: PanelTestPage.html)
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
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? extends Component 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] Closed: (WICKET-1619) PagingNavigator.setEnabled(false) doesn't work
[ https://issues.apache.org/jira/browse/WICKET-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Derugo closed WICKET-1619. - PagingNavigator.setEnabled(false) doesn't work --- Key: WICKET-1619 URL: https://issues.apache.org/jira/browse/WICKET-1619 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Reporter: Sergey Derugo Assignee: Igor Vaynberg Fix For: 1.3.6, 1.4-RC2 Attachments: 1619.patch 1. Create paging navigator PagingNavigator 2. call PagingNavigator.setEnabled(false) 3. navigator will be rendered as enabled, if click on any link (1, 2 etc) - content of the data view will be changed. In many cases it's necessary disable navigator, for example, when user need to edit only single line of DataView other controls need to be disabled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1489) Create component Menu
[ https://issues.apache.org/jira/browse/WICKET-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637089#action_12637089 ] Sergey Derugo commented on WICKET-1489: --- No, I haven't created the menu component. Create component Menu --- Key: WICKET-1489 URL: https://issues.apache.org/jira/browse/WICKET-1489 Project: Wicket Issue Type: New Feature Components: wicket-extensions Affects Versions: 1.3.2 Reporter: Sergey Derugo Fix For: 1.5-M1 Please implement component Menu. See example - http://www.telerik.com/products/aspnet/controls/menu/overview.aspx - this is menu component for ASP.NET (just look at the menu of this site - it's really nice). I think that Wicket should also have such component and this component should be included to the Wicket as standard control. For the begiging it will be nice to have menu the component with basic functionality. Then it will be possible add new features. -- 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 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: img src=../images/edit.gif 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 Possible solution: Wicket shouldn't override caching settings for images (*.gif, *.png etc.) Wicket shouldn't offer was: Steps to reproduce: 1. Create table(let's say 50 rows) using any repeater. 2. Add AjaxButton to each row, for example: img src=../images/edit.gif wicket:id=editButton alt=Edit/ - when user clicks on this button - the application also refreshes the entire table. 3. Since IE cannot cache images during AJAX updates it will take more time to re-load all images. 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. See details here http://www.bazon.net/mishoo/articles.epl?art_id=958 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 Possible solution: Wicket shouldn't override caching settings for images (*.gif, *.png etc.) Wicket shouldn't offer IE 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: img src=../images/edit.gif 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 Possible solution: Wicket shouldn't override caching settings for images (*.gif, *.png etc.) Wicket shouldn't offer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1858) IE image caching: performance issue during ajax updates
IE 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: img src=../images/edit.gif wicket:id=editButton alt=Edit/ - when user clicks on this button - the application also refreshes the entire table. 3. Since IE cannot cache images during AJAX updates it will take more time to re-load all images. 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. See details here http://www.bazon.net/mishoo/articles.epl?art_id=958 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 Possible solution: Wicket shouldn't override caching settings for images (*.gif, *.png etc.) Wicket shouldn't offer -- 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: img src=../images/edit.gif 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 noticably 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: img src=../images/edit.gif 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 Possible solution: Wicket shouldn't override caching settings for images (*.gif, *.png etc.) Wicket shouldn't offer Summary: IE 6 image caching: performance issue during ajax updates (was: IE image caching: performance issue during ajax updates) 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: img src=../images/edit.gif 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 noticably 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] Commented: (WICKET-1489) Create component Menu
[ https://issues.apache.org/jira/browse/WICKET-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606313#action_12606313 ] Sergey Derugo commented on WICKET-1489: --- You can adopt the menu component from here http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-contrib-yui/src/main/java/org/wicketstuff/yui/markup/html/menu2 See the example of usage http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-contrib-yui-examples Create component Menu --- Key: WICKET-1489 URL: https://issues.apache.org/jira/browse/WICKET-1489 Project: Wicket Issue Type: New Feature Components: wicket-extensions Affects Versions: 1.3.2 Reporter: Sergey Derugo Please implement component Menu. See example - http://www.telerik.com/products/aspnet/controls/menu/overview.aspx - this is menu component for ASP.NET (just look at the menu of this site - it's really nice). I think that Wicket should also have such component and this component should be included to the Wicket as standard control. For the begiging it will be nice to have menu the component with basic functionality. Then it will be possible add new features. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1619) PagingNavigator.setEnabled(false) doesn't work
PagingNavigator.setEnabled(false) doesn't work --- Key: WICKET-1619 URL: https://issues.apache.org/jira/browse/WICKET-1619 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Reporter: Sergey Derugo 1. Create paging navigator PagingNavigator 2. call PagingNavigator.setEnabled(false) 3. navigator will be rendered as enabled, if click on any link (1, 2 etc) - content of the data view will be changed. In many cases it's necessary disable navigator, for example, when user need to edit only single line of DataView other controls need to be disabled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1489) Create component Menu
Create component Menu --- Key: WICKET-1489 URL: https://issues.apache.org/jira/browse/WICKET-1489 Project: Wicket Issue Type: New Feature Components: wicket-extensions Affects Versions: 1.3.2 Reporter: Sergey Derugo Please implement component Menu. See example - http://www.telerik.com/products/aspnet/controls/menu/overview.aspx - this is menu component for ASP.NET (just look at the menu of this site - it's really nice). I think that Wicket should also have such component and this component should be included to the Wicket as standard control. For the begiging it will be nice to have menu the component with basic functionality. Then it will be possible add new features. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1491) ModalWindow: unclear exception if property Content is not set
ModalWindow: unclear exception if property Content is not set
---
Key: WICKET-1491
URL: https://issues.apache.org/jira/browse/WICKET-1491
Project: Wicket
Issue Type: Bug
Components: wicket-extensions
Affects Versions: 1.3.2
Reporter: Sergey Derugo
1. Create ModalWindow and don't set property *content* , for example:
{code}
package com.gfs.corp.bid.app.webcontrols.popup;
import org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow;
public class DialogMessage extends ModalWindow {
public DialogMessage(String id) {
super(id);
setTitle(popups.notification.header);
//setContent(new InformationMessageContent(getContentId()));
}
}
{code}
2. Create instance of DialogMessage and call method *show* - exception is
thrown:
message - WicketMessage: Error creating page for modal dialog.
Using this exception it's impossible to understand what is wrong. Either
exception message should be more detailed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1491) ModalWindow: unclear exception if property Content is not set
[
https://issues.apache.org/jira/browse/WICKET-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586458#action_12586458
]
Sergey Derugo commented on WICKET-1491:
---
Full stack trace:
WicketMessage: Error creating page for modal dialog.Root
cause:org.apache.wicket.WicketRuntimeException: Error creating page for modal
dialog. at
org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow.getWindowOpenJavascript(ModalWindow.java:932)
at
org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow.show(ModalWindow.java:279)
at test.demo.HomePage$1.onSubmit(HomePage.java:30) at
org.apache.wicket.ajax.markup.html.form.AjaxButton$1.onSubmit(AjaxButton.java:86)
at
org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:135)
at
org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:161)
at
org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:288)
at
org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:100)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:90)
at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1166)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1241) at
org.apache.wicket.RequestCycle.steps(RequestCycle.java:1316) at
org.apache.wicket.RequestCycle.request(RequestCycle.java:493) at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:354)
at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:194)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:619)
ModalWindow: unclear exception if property Content is not set
---
Key: WICKET-1491
URL: https://issues.apache.org/jira/browse/WICKET-1491
Project: Wicket
Issue Type: Bug
Components: wicket-extensions
Affects Versions: 1.3.2
Reporter: Sergey Derugo
1. Create ModalWindow and don't set property *content* , for example:
{code}
package com.gfs.corp.bid.app.webcontrols.popup;
import org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow;
public class DialogMessage extends ModalWindow {
public DialogMessage(String id) {
super(id);
setTitle(popups.notification.header);
//setContent(new InformationMessageContent(getContentId()));
}
}
{code}
2. Create instance of DialogMessage and call method *show* - exception is
thrown:
message - WicketMessage: Error creating page for modal dialog.
Using this exception it's impossible to understand what is wrong. Either
exception message should be more detailed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1491) ModalWindow: unclear exception if property Content is not set
[
https://issues.apache.org/jira/browse/WICKET-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586460#action_12586460
]
Sergey Derugo commented on WICKET-1491:
---
Full stack trace:
WicketMessage: Error creating page for modal dialog.
Root cause:
org.apache.wicket.WicketRuntimeException: Error creating page for modal dialog.
at
org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow.getWindowOpenJavascript(ModalWindow.java:932)
at
org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow.show(ModalWindow.java:279)
at test.demo.HomePage$1.onSubmit(HomePage.java:30)
at
org.apache.wicket.ajax.markup.html.form.AjaxButton$1.onSubmit(AjaxButton.java:86)
at
org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:135)
at
org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:161)
at
org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:288)
at
org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:100)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:90)
at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1166)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1241)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1316)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:493)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:354)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:194)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:619)
ModalWindow: unclear exception if property Content is not set
---
Key: WICKET-1491
URL: https://issues.apache.org/jira/browse/WICKET-1491
Project: Wicket
Issue Type: Bug
Components: wicket-extensions
Affects Versions: 1.3.2
Reporter: Sergey Derugo
1. Create ModalWindow and don't set property *content* , for example:
{code}
package test.demo.webcontrols.popup;
import org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow;
public class DialogMessage extends ModalWindow {
public DialogMessage(String id) {
super(id);
setTitle(popups.notification.header);
//setContent(new InformationMessageContent(getContentId()));
}
}
{code}
2. Create instance of DialogMessage and call method *show* - exception is
thrown:
message - WicketMessage: Error creating page for modal dialog.
Using this exception it's impossible to understand what is wrong. Either
exception message should be more detailed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1491) ModalWindow: unclear exception if property Content is not set
[
https://issues.apache.org/jira/browse/WICKET-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586461#action_12586461
]
Sergey Derugo commented on WICKET-1491:
---
Please make exception message more obvious.
ModalWindow: unclear exception if property Content is not set
---
Key: WICKET-1491
URL: https://issues.apache.org/jira/browse/WICKET-1491
Project: Wicket
Issue Type: Bug
Components: wicket-extensions
Affects Versions: 1.3.2
Reporter: Sergey Derugo
1. Create ModalWindow and don't set property *content* , for example:
{code}
package test.demo.webcontrols.popup;
import org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow;
public class DialogMessage extends ModalWindow {
public DialogMessage(String id) {
super(id);
setTitle(popups.notification.header);
//setContent(new InformationMessageContent(getContentId()));
}
}
{code}
2. Create instance of DialogMessage and call method *show* - exception is
thrown:
message - WicketMessage: Error creating page for modal dialog.
Using this exception it's impossible to understand what is wrong. Either
exception message should be more detailed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1235) First-time request doesn't respect XML page and Form encoding
[
https://issues.apache.org/jira/browse/WICKET-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561289#action_12561289
]
Sergey Derugo commented on WICKET-1235:
---
Thy this approach http://anydoby.com/jblog/article.htm?id=37
First-time request doesn't respect XML page and Form encoding
-
Key: WICKET-1235
URL: https://issues.apache.org/jira/browse/WICKET-1235
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.0-rc2
Environment: Windows 2000, jdk1.4.2_14-b05, Apache Tomcat 4.1.36-LE,
Wicket 1.3.0-rc2
Reporter: Evgeniy Karyakin
Attachments: Wicket13Test.jar, Wicket13Test.war
One test page with ?xml version=1.0 encoding=UTF-8? XML declaration in
it (Wicket13TestHomePage.html):
?xml version=1.0 encoding=UTF-8?
!DOCTYPE html
PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns:wicket=http://wicket.sourceforge.net/;
head
titleWicket13Test/title
/head
body
!-- Form in question --
form wicket:id=testform accept-charset=UTF-8
input type=text wicket:id=inputtest/
input type=submit/
/form
!-- /Form --
/body
/html
WebApplication implementation set application-wide response-request encoding
to UTF-8:
package com.example.wicket13test;
import org.apache.wicket.protocol.http.WebApplication;
public class Wicket13TestApplication extends WebApplication {
public Wicket13TestApplication() {
}
public Class getHomePage() {
return Wicket13TestHomePage.class;
}
public void init() {
super.init();
getRequestCycleSettings().setResponseRequestEncoding(UTF-8);
}
}
FIRST browser request of http://localhost/Wicket13Test/ gives this response
headers:
HTTP/1.x 200 OK
Server: Apache-Coyote/1.1
Pragma: no-cache
Cache-Control: no-cache, max-age=0, must-revalidate
Content-Type: text/html;charset=ISO-8859-5
Content-Language: ru-RU
Content-Length: 638
Date: Tue, 18 Dec 2007 09:31:04 GMT
That is, Content-Type is ISO-8859-5 (JVM's default?), but I assume it should
already be UTF-8. Second and consequent requests result in proper response
encoding: Content-Type: text/html;charset=UTF-8. Hands-on web experience
says that browser makes form submission using character encoding based on
last response's setting. So this situation leads to wrong *first-time* form
submission, but second ones are fine. In Firefox 2 form's accept-charset
attributes helps forcibly set desired encoding, but in MSIE it doesn't.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1287) Links on the main page are not clicable under IE 6
[
https://issues.apache.org/jira/browse/WICKET-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561038#action_12561038
]
Sergey Derugo commented on WICKET-1287:
---
Thank you
Links on the main page are not clicable under IE 6
--
Key: WICKET-1287
URL: https://issues.apache.org/jira/browse/WICKET-1287
Project: Wicket
Issue Type: Bug
Components: wicket-examples
Affects Versions: 1.3.0-rc2
Environment: Live Demo http://wicketstuff.org/wicket13/
Windows XP SP 2, IE 6.0
Reporter: Sergey Derugo
Assignee: Gerolf Seitz
Priority: Minor
Fix For: 1.3.0-final
Attachments: IE.PNG
Steps to reproduce:
1. Open IE 6
2. Go to http://wicketstuff.org/wicket13/
3. All links to the examples are not clickable
It seems tha the problem is caused by ie.css for this demo. Please look at
is.css:
#container {
background-image: none;
filter:progid:DXimageTransform.Microsoft.AlphaimageLoader(src='images/bg_container.png',
sizingMethod='scale');
If simply use background-image: url('images/bg_container.png') - all links
are clickable
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (WICKET-1287) Links on the main page are not clicable under IE 6
[
https://issues.apache.org/jira/browse/WICKET-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Derugo reopened WICKET-1287:
---
1. The issue was reported to the public demo http://wicketstuff.org/wicket13/
and still reproducible. What version is currently deployed on this server?
2. I attached information about the browser. Please feel free to request any
additional details if it help you to resolve the problem.
Links on the main page are not clicable under IE 6
--
Key: WICKET-1287
URL: https://issues.apache.org/jira/browse/WICKET-1287
Project: Wicket
Issue Type: Bug
Components: wicket-examples
Affects Versions: 1.3.0-rc2
Environment: Live Demo http://wicketstuff.org/wicket13/
Windows XP SP 2, IE 6.0
Reporter: Sergey Derugo
Assignee: Gerolf Seitz
Priority: Minor
Fix For: 1.3.0-final
Attachments: IE.PNG
Steps to reproduce:
1. Open IE 6
2. Go to http://wicketstuff.org/wicket13/
3. All links to the examples are not clickable
It seems tha the problem is caused by ie.css for this demo. Please look at
is.css:
#container {
background-image: none;
filter:progid:DXimageTransform.Microsoft.AlphaimageLoader(src='images/bg_container.png',
sizingMethod='scale');
If simply use background-image: url('images/bg_container.png') - all links
are clickable
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1287) Links on the main page are not clicable under IE 6
Links on the main page are not clicable under IE 6
--
Key: WICKET-1287
URL: https://issues.apache.org/jira/browse/WICKET-1287
Project: Wicket
Issue Type: Bug
Components: wicket-examples
Affects Versions: 1.3.0-final
Environment: Live Demo http://wicketstuff.org/wicket13/
Windows XP SP 2, IE 6.0
Reporter: Sergey Derugo
Priority: Blocker
Steps to reproduce:
1. Open IE 6
2. Go to http://wicketstuff.org/wicket13/
3. All links to the examples are not clickable
It seems tha the problem is caused by ie.css for this demo. Please look at
{code}
#container {
background-image: none;
filter:progid:DXimageTransform.Microsoft.AlphaimageLoader(src='images/bg_container.png',
sizingMethod='scale');
}
{code}
If replace use simply background-image: url('images/bg_container.png') - all
links are clickable
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
