[jira] [Created] (WICKET-3557) Can not add validator to AjaxEditableLabel unless it was added to page
Can not add validator to AjaxEditableLabel unless it was added to page -- Key: WICKET-3557 URL: https://issues.apache.org/jira/browse/WICKET-3557 Project: Wicket Issue Type: Bug Components: wicket-extensions Reporter: Erik van Oosten Priority: Minor Method AjaxEditableLabel#add(IValidator) tries to add the validator to the editor. As the editor initiaily does not exist, it is created. Creation of the editor fails when the component has not been added to the page yet. Workaround: add the AjaxEditableLabel to page before adding the validator(s). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-1973) Messages lost upon session failover with redirect_to_buffer
[ https://issues.apache.org/jira/browse/WICKET-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12975285#action_12975285 ] Erik van Oosten commented on WICKET-1973: - The other use case is the odd-client that insists on using a round robin load balancer. Messages lost upon session failover with redirect_to_buffer --- Key: WICKET-1973 URL: https://issues.apache.org/jira/browse/WICKET-1973 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-RC1 Reporter: Erik van Oosten Using the redirect_to_buffer render strategy, messages in the session get cleared after the render. If the redirected request comes in at another node, the buffer is not found and the page is re-rendered. In this case the messages are no longer available. See the javadoc of WebApplication#popBufferedResponse(String,String). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1973) Messages lost upon session failover with redirect_to_buffer
[ https://issues.apache.org/jira/browse/WICKET-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12975442#action_12975442 ] Erik van Oosten commented on WICKET-1973: - None from me. Messages lost upon session failover with redirect_to_buffer --- Key: WICKET-1973 URL: https://issues.apache.org/jira/browse/WICKET-1973 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-RC1 Reporter: Erik van Oosten Using the redirect_to_buffer render strategy, messages in the session get cleared after the render. If the redirected request comes in at another node, the buffer is not found and the page is re-rendered. In this case the messages are no longer available. See the javadoc of WebApplication#popBufferedResponse(String,String). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903873#action_12903873 ] Erik van Oosten commented on WICKET-1355: - Thanks Igor. But indeed, lets just drop it. The situation in which this happens is too specific (and hard to reproduce), and apparently hard to solve in all browsers, to warrant large changes. Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Assignee: Igor Vaynberg Attachments: Safari autocomplete in Modal Window.jpg, wicket-1355-wicket-1.3.x-autocomplete.patch, wicket-1355-wicket-1.4.x-autocomplete.patch, wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2846) Store Application in InheritableThreadLocal instead of ThreadLocal
[
https://issues.apache.org/jira/browse/WICKET-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12888729#action_12888729
]
Erik van Oosten commented on WICKET-2846:
-
Juliano Viana on the WIcket user mailing list at 2010-07-14 15:55 wrote:
Hi everyone,
I know this issue has already been debated and that a decision was made to
revert this change in a future version of Wicket.
However, the discussions about this issue were centered on the fact starting
threads in web applications is not a good idea anyway, and hence this would
not break applications that are not already broken.
I have found a real case where this breaks an innocent application:
redeploying an application based on Wicket 1.4.9 on Glassfish 3.0.1 causes
a memory leak due to the use of InheritableThreadLocal.
The problem is that when the application accesses a JDBC resource for the
first time, Glassfish lazily starts a timer (connector-timer-proxy) that has
an associated thread. This timer is started from the web request processing
thread. This thread never dies, and inherits a reference to the Wicket
Application object.
This only happens on redeployments, but it really hurts development as you
keep having to restart Glassfish due to OOM exceptions.
Removing the InheritableThreadLocal resolves the issue completely and makes
development really smooth again.
So if you are using Wicket 1.4.9 with Glassfish v3 you should consider
patching it until a new Wicket release is out.
Regards,
- Juliano
Store Application in InheritableThreadLocal instead of ThreadLocal
--
Key: WICKET-2846
URL: https://issues.apache.org/jira/browse/WICKET-2846
Project: Wicket
Issue Type: Improvement
Components: wicket
Reporter: Alexandru Objelean
Assignee: Jeremy Thomerson
Priority: Minor
Fix For: 1.4.10
Attachments: wicket-application-leak.tar.gz
Is there any particular reason why Application class wouldn't be stored in
InheritableThreadLocal instead of ThreadLocal? The problem is that I need to
be able to access Application class from a thread created when a button is
pressed. Using InheritableThreadLocal instead of ThreadLocal would solve
this problem.
Use case example:
public class MyPage extends Page {
@SpringBean
private MyService service;
//perform a polling of long running process triggered by a button click
onClickButton() {
new Thread() {
run() {
service.executeLongRunningProcess();
}
}.start();
}
}
The following example won't work well if the Application is not stored in
InheritableThreadLocal. The reason why it doesn't work, as I understand that,
is because @SpringBean lookup depends on Application instance which is not
accessible from within the thread. Having it stored inside of ITL would solve
the problem.
Thanks!
Alex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2881) Cannot substitute RelativePathPrefixHandler
[
https://issues.apache.org/jira/browse/WICKET-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12880475#action_12880475
]
Erik van Oosten commented on WICKET-2881:
-
[WICKET-1974] provides an alternative way to get rid of relative paths.
Cannot substitute RelativePathPrefixHandler
---
Key: WICKET-2881
URL: https://issues.apache.org/jira/browse/WICKET-2881
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.4.8
Environment: All
Reporter: bernard
Attachments: DirectoryStructure.gif, HomePage.html
In IPageSettings
Get the (modifiable) list of IComponentResolvers.
ListIComponentResolver getComponentResolvers();
This looks very useful and easy indeed, and in Application.init() one can
find and remove
RelativePathPrefixHandler and replace it with a different
AbstractMarkupFilter implementation e.g. XRelativePathPrefixHandler.
But even while the List.remove(Object o) returns true, and the handler
appears to be removed, it is still active.
I don't know why and what holds on to it or what creates a new
RelativePathPrefixHandler.
If I add my XRelativePathPrefixHandler, it is not used.
Consider
public class MarkupParser
public final void appendMarkupFilter(final IMarkupFilter filter)
{
appendMarkupFilter(filter, RelativePathPrefixHandler.class);
}
So RelativePathPrefixHandler seems to be something special and I am afraid of
other potential complications in case replacement would work.
Can Wicket be fixed to make a replacement as easy as it appears to be?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2631) wicket:message within wicket:head not processed
[ https://issues.apache.org/jira/browse/WICKET-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2631: Attachment: messageintitle-quickstart.tar.gz Quickstart to demonstrate that the problem persists in Wicket 1.4.9. wicket:message within wicket:head not processed --- Key: WICKET-2631 URL: https://issues.apache.org/jira/browse/WICKET-2631 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4.1 Reporter: Ivo Maixner Assignee: Juergen Donnerstag Priority: Minor Attachments: messageintitle-quickstart.tar.gz My pages extend a base page, so they use the wicket:extend tag. For such a page to specify its html title, the wicket:head tag has to be used. At the same time, my pages require localization, so the page title cannot be hardcoded but needs to be loaded from properties files instead, so I have to use the wicket:message tag inside the wicket:head tag. Overall, the page looks like this: wicket:head titlewicket:message key=page_title[page_title]/wicket:message/title /wicket:head wicket:extend ... page content ... /wicket:extend In this setup, the content of the title html tag is passed over to the page as-is, i.e. the wicket:message tag is not recognized and processed by Wicket. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2631) wicket:message within wicket:head not processed
[ https://issues.apache.org/jira/browse/WICKET-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2631: Comment: was deleted (was: Seeing the same here in Wicket 1.4.9. Will try to reproduce it in a quickstart.) wicket:message within wicket:head not processed --- Key: WICKET-2631 URL: https://issues.apache.org/jira/browse/WICKET-2631 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4.1 Reporter: Ivo Maixner Assignee: Juergen Donnerstag Priority: Minor My pages extend a base page, so they use the wicket:extend tag. For such a page to specify its html title, the wicket:head tag has to be used. At the same time, my pages require localization, so the page title cannot be hardcoded but needs to be loaded from properties files instead, so I have to use the wicket:message tag inside the wicket:head tag. Overall, the page looks like this: wicket:head titlewicket:message key=page_title[page_title]/wicket:message/title /wicket:head wicket:extend ... page content ... /wicket:extend In this setup, the content of the title html tag is passed over to the page as-is, i.e. the wicket:message tag is not recognized and processed by Wicket. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2631) wicket:message within wicket:head not processed
[ https://issues.apache.org/jira/browse/WICKET-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2631: Attachment: (was: messageintitle-quickstart.tar.gz) wicket:message within wicket:head not processed --- Key: WICKET-2631 URL: https://issues.apache.org/jira/browse/WICKET-2631 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4.1 Reporter: Ivo Maixner Assignee: Juergen Donnerstag Priority: Minor My pages extend a base page, so they use the wicket:extend tag. For such a page to specify its html title, the wicket:head tag has to be used. At the same time, my pages require localization, so the page title cannot be hardcoded but needs to be loaded from properties files instead, so I have to use the wicket:message tag inside the wicket:head tag. Overall, the page looks like this: wicket:head titlewicket:message key=page_title[page_title]/wicket:message/title /wicket:head wicket:extend ... page content ... /wicket:extend In this setup, the content of the title html tag is passed over to the page as-is, i.e. the wicket:message tag is not recognized and processed by Wicket. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2631) wicket:message within wicket:head not processed
[ https://issues.apache.org/jira/browse/WICKET-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2631: Comment: was deleted (was: Quickstart to demonstrate that the problem persists in Wicket 1.4.9.) wicket:message within wicket:head not processed --- Key: WICKET-2631 URL: https://issues.apache.org/jira/browse/WICKET-2631 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4.1 Reporter: Ivo Maixner Assignee: Juergen Donnerstag Priority: Minor My pages extend a base page, so they use the wicket:extend tag. For such a page to specify its html title, the wicket:head tag has to be used. At the same time, my pages require localization, so the page title cannot be hardcoded but needs to be loaded from properties files instead, so I have to use the wicket:message tag inside the wicket:head tag. Overall, the page looks like this: wicket:head titlewicket:message key=page_title[page_title]/wicket:message/title /wicket:head wicket:extend ... page content ... /wicket:extend In this setup, the content of the title html tag is passed over to the page as-is, i.e. the wicket:message tag is not recognized and processed by Wicket. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2631) wicket:message within wicket:head not processed
[ https://issues.apache.org/jira/browse/WICKET-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12879704#action_12879704 ] Erik van Oosten commented on WICKET-2631: - Don't forget to call getMarkupSettings().setStripWicketTags(true); in the init() of your WebApplication subclass. If you don't the wicket:message elements will be displayed by the browser as part of the title. wicket:message within wicket:head not processed --- Key: WICKET-2631 URL: https://issues.apache.org/jira/browse/WICKET-2631 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4.1 Reporter: Ivo Maixner Assignee: Juergen Donnerstag Priority: Minor My pages extend a base page, so they use the wicket:extend tag. For such a page to specify its html title, the wicket:head tag has to be used. At the same time, my pages require localization, so the page title cannot be hardcoded but needs to be loaded from properties files instead, so I have to use the wicket:message tag inside the wicket:head tag. Overall, the page looks like this: wicket:head titlewicket:message key=page_title[page_title]/wicket:message/title /wicket:head wicket:extend ... page content ... /wicket:extend In this setup, the content of the title html tag is passed over to the page as-is, i.e. the wicket:message tag is not recognized and processed by Wicket. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2631) wicket:message within wicket:head not processed
[ https://issues.apache.org/jira/browse/WICKET-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12878955#action_12878955 ] Erik van Oosten commented on WICKET-2631: - Seeing the same here in Wicket 1.4.9. Will try to reproduce it in a quickstart. wicket:message within wicket:head not processed --- Key: WICKET-2631 URL: https://issues.apache.org/jira/browse/WICKET-2631 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4.1 Reporter: Ivo Maixner Assignee: Juergen Donnerstag Priority: Minor My pages extend a base page, so they use the wicket:extend tag. For such a page to specify its html title, the wicket:head tag has to be used. At the same time, my pages require localization, so the page title cannot be hardcoded but needs to be loaded from properties files instead, so I have to use the wicket:message tag inside the wicket:head tag. Overall, the page looks like this: wicket:head titlewicket:message key=page_title[page_title]/wicket:message/title /wicket:head wicket:extend ... page content ... /wicket:extend In this setup, the content of the title html tag is passed over to the page as-is, i.e. the wicket:message tag is not recognized and processed by Wicket. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1469) New Wicket tag 'wicket:for'
[ https://issues.apache.org/jira/browse/WICKET-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-1469: Attachment: WICKET-1469-for-wicket-1.4.x.patch Attachment WICKET-1469-for-wicket-1.4.x.patch can be applied to branch 1.4.x. Supported: - wicket:for attribute, value refers to any component - during rendering the for attribute is generated with as value the referred component's markup id - referred component's will automatically render its markup id when it is located /after/ the wicket:for attribute in the markup stream Not supported: - referred component will /not/ automatically render its markup id when it is located before the wicket:for attribute in the markup stream Any clues on how to support the latter are much appreciated. The alternative is to remove auto rendering of markup ids completely. New Wicket tag 'wicket:for' --- Key: WICKET-1469 URL: https://issues.apache.org/jira/browse/WICKET-1469 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.3.2 Reporter: Jan Kriesten Priority: Minor Fix For: 1.5-M1 Attachments: WICKET-1469-for-wicket-1.4.x.patch This often happens during my daily work: You create a form with labels and corresponding input fields. As it is now, you have to bind all those Labels and FormComponents together with some boilerplate code within Java. I'd like to suggest the following enhancement Wicket tag: label wicket:for=username wicket:messge=keydefault message/label where wicket:for contains the referenced wicket:id -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (WICKET-2602) Display upload progress bar only when a file is selected
[ https://issues.apache.org/jira/browse/WICKET-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten reopened WICKET-2602: - Pleas apply attached patch to optimize serialization. Display upload progress bar only when a file is selected Key: WICKET-2602 URL: https://issues.apache.org/jira/browse/WICKET-2602 Project: Wicket Issue Type: Improvement Components: wicket-extensions Reporter: Erik van Oosten Assignee: Igor Vaynberg Fix For: 1.4.5, 1.5-M1 Attachments: Serialization_optimization_.patch, WICKET-2602-1.3.patch, WICKET-2602-1.4_and_1.5.patch When the UploadProgressBar is part of a larger form structure where not all submits actually start a file upload, it is disturbing to see the 'upload starting...' message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2602) Display upload progress bar only when a file is selected
[ https://issues.apache.org/jira/browse/WICKET-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2602: Attachment: Serialization_optimization_.patch Display upload progress bar only when a file is selected Key: WICKET-2602 URL: https://issues.apache.org/jira/browse/WICKET-2602 Project: Wicket Issue Type: Improvement Components: wicket-extensions Reporter: Erik van Oosten Assignee: Igor Vaynberg Fix For: 1.4.5, 1.5-M1 Attachments: Serialization_optimization_.patch, WICKET-2602-1.3.patch, WICKET-2602-1.4_and_1.5.patch When the UploadProgressBar is part of a larger form structure where not all submits actually start a file upload, it is disturbing to see the 'upload starting...' message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1469) New Wicket tag 'wicket:for'
[ https://issues.apache.org/jira/browse/WICKET-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12790036#action_12790036 ] Erik van Oosten commented on WICKET-1469: - See e-mail discussion: http://old.nabble.com/Request-for-input-on-new-feature-idea%3A-wicket%3Afor-attribute-td26765933.html New Wicket tag 'wicket:for' --- Key: WICKET-1469 URL: https://issues.apache.org/jira/browse/WICKET-1469 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.3.2 Reporter: Jan Kriesten Priority: Minor Fix For: 1.5-M1 This often happens during my daily work: You create a form with labels and corresponding input fields. As it is now, you have to bind all those Labels and FormComponents together with some boilerplate code within Java. I'd like to suggest the following enhancement Wicket tag: label wicket:for=username wicket:messge=keydefault message/label where wicket:for contains the referenced wicket:id -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2602) Delay display of upload progress bar
[ https://issues.apache.org/jira/browse/WICKET-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12787976#action_12787976 ] Erik van Oosten commented on WICKET-2602: - I deleted the patch as I have a new patch in the making that will detect if a file will actually be uploaded for a specific file field. Delay display of upload progress bar Key: WICKET-2602 URL: https://issues.apache.org/jira/browse/WICKET-2602 Project: Wicket Issue Type: Improvement Components: wicket-extensions Reporter: Erik van Oosten When the UploadProgressBar is part of a larger form structure where not all submits actually start a file upload, it is disturbing to see the 'upload starting...' message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2602) Delay display of upload progress bar
[ https://issues.apache.org/jira/browse/WICKET-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2602: Comment: was deleted (was: Please apply this patch to: - trunk - branch 1.4.x - branch 1.3.x) Delay display of upload progress bar Key: WICKET-2602 URL: https://issues.apache.org/jira/browse/WICKET-2602 Project: Wicket Issue Type: Improvement Components: wicket-extensions Reporter: Erik van Oosten When the UploadProgressBar is part of a larger form structure where not all submits actually start a file upload, it is disturbing to see the 'upload starting...' message. The patch will display the upload bar only after 1 second. Presumably a submit without file will be finished by then. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2602) Delay display of upload progress bar
[ https://issues.apache.org/jira/browse/WICKET-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2602: Attachment: (was: WICKET-2602.patch) Delay display of upload progress bar Key: WICKET-2602 URL: https://issues.apache.org/jira/browse/WICKET-2602 Project: Wicket Issue Type: Improvement Components: wicket-extensions Reporter: Erik van Oosten When the UploadProgressBar is part of a larger form structure where not all submits actually start a file upload, it is disturbing to see the 'upload starting...' message. The patch will display the upload bar only after 1 second. Presumably a submit without file will be finished by then. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2602) Delay display of upload progress bar
[ https://issues.apache.org/jira/browse/WICKET-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2602: Description: When the UploadProgressBar is part of a larger form structure where not all submits actually start a file upload, it is disturbing to see the 'upload starting...' message. (was: When the UploadProgressBar is part of a larger form structure where not all submits actually start a file upload, it is disturbing to see the 'upload starting...' message. The patch will display the upload bar only after 1 second. Presumably a submit without file will be finished by then.) Delay display of upload progress bar Key: WICKET-2602 URL: https://issues.apache.org/jira/browse/WICKET-2602 Project: Wicket Issue Type: Improvement Components: wicket-extensions Reporter: Erik van Oosten When the UploadProgressBar is part of a larger form structure where not all submits actually start a file upload, it is disturbing to see the 'upload starting...' message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2602) Delay display of upload progress bar
[ https://issues.apache.org/jira/browse/WICKET-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2602: Comment: was deleted (was: An even better fix would show the upload bar only when there is a file to upload.) Delay display of upload progress bar Key: WICKET-2602 URL: https://issues.apache.org/jira/browse/WICKET-2602 Project: Wicket Issue Type: Improvement Components: wicket-extensions Reporter: Erik van Oosten When the UploadProgressBar is part of a larger form structure where not all submits actually start a file upload, it is disturbing to see the 'upload starting...' message. The patch will display the upload bar only after 1 second. Presumably a submit without file will be finished by then. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2600) Redirect to home page still does not work (regression)
[ https://issues.apache.org/jira/browse/WICKET-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12787981#action_12787981 ] Erik van Oosten commented on WICKET-2600: - Yes, I tested this with Firefox 3.5 (Ubuntu), Chrome 3.0 (Windows), and IE 5.5, 6, 7 and 8. BTW, it is within reason that any other browser that understands ./ will also understand .. Redirect to home page still does not work (regression) -- Key: WICKET-2600 URL: https://issues.apache.org/jira/browse/WICKET-2600 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.7, 1.4.4, 1.5-M1 Reporter: Erik van Oosten Attachments: WICKET-2600.patch It is still not possible to redirect to the home under all circumstances with Tomcat + IE (6, 7 and 8). WICKET-847 fixed a problem by removing any ./ at the start of the redirect URL. WICKET-1916 undid this for redirect URLs that are exactly equal to ./. The latter fix is not correct, IE can not redirect to ./. The correct addition to WICKET-847 would be to redirect to .. See patch. -- 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-2600) Redirect to home page still does not work (regression)
[ https://issues.apache.org/jira/browse/WICKET-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12787981#action_12787981 ] Erik van Oosten edited comment on WICKET-2600 at 12/9/09 9:10 AM: -- Yes, I tested this with Firefox 3.5 (Ubuntu), Chrome 3.0 (Windows), and IE 5.5, 6, 7 and 8. BTW, it is within reason that any other browser that understands ./ will also understand .. Under this assumption the patch can make the situation only better, not worse. was (Author: erikvanoosten): Yes, I tested this with Firefox 3.5 (Ubuntu), Chrome 3.0 (Windows), and IE 5.5, 6, 7 and 8. BTW, it is within reason that any other browser that understands ./ will also understand .. Redirect to home page still does not work (regression) -- Key: WICKET-2600 URL: https://issues.apache.org/jira/browse/WICKET-2600 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.7, 1.4.4, 1.5-M1 Reporter: Erik van Oosten Attachments: WICKET-2600.patch It is still not possible to redirect to the home under all circumstances with Tomcat + IE (6, 7 and 8). WICKET-847 fixed a problem by removing any ./ at the start of the redirect URL. WICKET-1916 undid this for redirect URLs that are exactly equal to ./. The latter fix is not correct, IE can not redirect to ./. The correct addition to WICKET-847 would be to redirect to .. See patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2602) Do not display upload progress bar when no file is selected
[ https://issues.apache.org/jira/browse/WICKET-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2602: Summary: Do not display upload progress bar when no file is selected (was: Delay display of upload progress bar) Do not display upload progress bar when no file is selected --- Key: WICKET-2602 URL: https://issues.apache.org/jira/browse/WICKET-2602 Project: Wicket Issue Type: Improvement Components: wicket-extensions Reporter: Erik van Oosten Attachments: WICKET-2602-1.3.patch, WICKET-2602-1.4_and_1.5.patch When the UploadProgressBar is part of a larger form structure where not all submits actually start a file upload, it is disturbing to see the 'upload starting...' message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2602) Delay display of upload progress bar
[ https://issues.apache.org/jira/browse/WICKET-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2602: Attachment: WICKET-2602-1.4_and_1.5.patch WICKET-2602-1.3.patch These patches add the option to make UploadProgressBar only display the progress upload bar when a file is selected. Please apply the 1.3 patch in branch 1.3.x. Please apply the 1.4_and_1.5 patch in trunk and branch 1.4.x. Delay display of upload progress bar Key: WICKET-2602 URL: https://issues.apache.org/jira/browse/WICKET-2602 Project: Wicket Issue Type: Improvement Components: wicket-extensions Reporter: Erik van Oosten Attachments: WICKET-2602-1.3.patch, WICKET-2602-1.4_and_1.5.patch When the UploadProgressBar is part of a larger form structure where not all submits actually start a file upload, it is disturbing to see the 'upload starting...' message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2602) Do not display upload progress bar when no file is selected
[ https://issues.apache.org/jira/browse/WICKET-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12788023#action_12788023 ] Erik van Oosten commented on WICKET-2602: - Tested the patch with Chrome 3.0 (Windows), IE 8.0 and Firefox 3.5 (Ubuntu). Do not display upload progress bar when no file is selected --- Key: WICKET-2602 URL: https://issues.apache.org/jira/browse/WICKET-2602 Project: Wicket Issue Type: Improvement Components: wicket-extensions Reporter: Erik van Oosten Attachments: WICKET-2602-1.3.patch, WICKET-2602-1.4_and_1.5.patch When the UploadProgressBar is part of a larger form structure where not all submits actually start a file upload, it is disturbing to see the 'upload starting...' message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2602) Do not display upload progress bar when no file is selected
[ https://issues.apache.org/jira/browse/WICKET-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2602: Comment: was deleted (was: I deleted the patch as I have a new patch in the making that will detect if a file will actually be uploaded for a specific file field.) Do not display upload progress bar when no file is selected --- Key: WICKET-2602 URL: https://issues.apache.org/jira/browse/WICKET-2602 Project: Wicket Issue Type: Improvement Components: wicket-extensions Reporter: Erik van Oosten Attachments: WICKET-2602-1.3.patch, WICKET-2602-1.4_and_1.5.patch When the UploadProgressBar is part of a larger form structure where not all submits actually start a file upload, it is disturbing to see the 'upload starting...' message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2600) Redirect to home page still does not work (regression)
Redirect to home page still does not work (regression) -- Key: WICKET-2600 URL: https://issues.apache.org/jira/browse/WICKET-2600 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4.4, 1.3.7, 1.5-M1 Reporter: Erik van Oosten It is still not possible to redirect to the home under all circumstances with Tomcat + IE (6, 7 and 8). WICKET-847 fixed a problem by removing any ./ at the start of the redirect URL. WICKET-1916 undid this for redirect URLs that are exactly equal to ./. The latter fix is not correct, IE can not redirect to ./. The correct addition to WICKET-847 would be to redirect to .. See patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2600) Redirect to home page still does not work (regression)
[ https://issues.apache.org/jira/browse/WICKET-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2600: Attachment: WICKET-2600.patch Patch can be applied in: - trunk - branch 1.4.x - branch 1.3.x Redirect to home page still does not work (regression) -- Key: WICKET-2600 URL: https://issues.apache.org/jira/browse/WICKET-2600 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.7, 1.4.4, 1.5-M1 Reporter: Erik van Oosten Attachments: WICKET-2600.patch It is still not possible to redirect to the home under all circumstances with Tomcat + IE (6, 7 and 8). WICKET-847 fixed a problem by removing any ./ at the start of the redirect URL. WICKET-1916 undid this for redirect URLs that are exactly equal to ./. The latter fix is not correct, IE can not redirect to ./. The correct addition to WICKET-847 would be to redirect to .. See patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2602) Delay display of upload progress bar
[ https://issues.apache.org/jira/browse/WICKET-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2602: Attachment: WICKET-2602.patch Please apply this patch to: - trunk - branch 1.4.x - branch 1.3.x Delay display of upload progress bar Key: WICKET-2602 URL: https://issues.apache.org/jira/browse/WICKET-2602 Project: Wicket Issue Type: Improvement Components: wicket-extensions Reporter: Erik van Oosten Attachments: WICKET-2602.patch When the UploadProgressBar is part of a larger form structure where not all submits actually start a file upload, it is disturbing to see the 'upload starting...' message. The patch will display the upload bar only after 1 second. Presumably a submit without file will be finished by then. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2602) Delay display of upload progress bar
[ https://issues.apache.org/jira/browse/WICKET-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12787513#action_12787513 ] Erik van Oosten commented on WICKET-2602: - An even better fix would show the upload bar only when there is a file to upload. Delay display of upload progress bar Key: WICKET-2602 URL: https://issues.apache.org/jira/browse/WICKET-2602 Project: Wicket Issue Type: Improvement Components: wicket-extensions Reporter: Erik van Oosten Attachments: WICKET-2602.patch When the UploadProgressBar is part of a larger form structure where not all submits actually start a file upload, it is disturbing to see the 'upload starting...' message. The patch will display the upload bar only after 1 second. Presumably a submit without file will be finished by then. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12785895#action_12785895 ] Erik van Oosten commented on WICKET-1355: - One disadvantage of positioning the div as sibling of the textfield is that the dropdown div will never be able to extend the area of the first parent with position absolute. I.e. you need to make sure that there is enough room below the textfield within the parent (make sure some more input fields follow, or just add some empty space). This will happen with modal windows, but this will not be a problem at all when you have no such parent. This disadvantage outweights the disadvantage of having no visible dropdown div at all. Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Assignee: Igor Vaynberg Attachments: wicket-1355-wicket-1.3.x-autocomplete.patch, wicket-1355-wicket-1.4.x-autocomplete.patch, wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2579) tabbedpanel (and ajaxtabbedpanel) only submit the selected tab. A mode which instead submits all loaded tabs would be helpful.
[ https://issues.apache.org/jira/browse/WICKET-2579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12779860#action_12779860 ] Erik van Oosten commented on WICKET-2579: - Roger, please note that what you ask is not weird, its just that it can not be accomplish with the current TabbedPanel. Another component that does what you ask would be welcome of course. tabbedpanel (and ajaxtabbedpanel) only submit the selected tab. A mode which instead submits all loaded tabs would be helpful. -- Key: WICKET-2579 URL: https://issues.apache.org/jira/browse/WICKET-2579 Project: Wicket Issue Type: Wish Components: wicket-extensions Affects Versions: 1.4.3 Reporter: Roger Armstrong Assignee: Igor Vaynberg If I want to split the contents of a form across multiple tabs (for example a user profile form split into basic and advanced settings), there seems to be no way to validate the form properly. The user should be able to fill out, say, first name and last name in the basic tab, then switch to the advanced tab and fill out some settings there, then click the Save button. If the user forgot to fill out a required field on the basic, (say, email address), there's no way to handle this (because the first tab is already gone when you switch to the second tab). I've tried to use an AjaxFormValidatingBehavior on blur of all form components, but this is not a good solution since validation occurs on lost focus instead of when the user clicks the Save button. What I would like would be that the TabbedPanel keeps all visited panels around (but all hidden except the selected tab) so that they are all submitted together. That way, you have lazy loading, but standard submit and validate behavior (at the expense of keeping the loaded panels around). This seems like a fairly standard pattern for using a tabbed panel, so it would seem useful to have it in the standard tab panel instead of everyone having to reinvent it (like at http://www.xaloon.org/blog/advanced-wicket-tabs-with-jquery). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2580) Javadoc of Component#setOutputMarkupPlaceholderTag is wrong
Javadoc of Component#setOutputMarkupPlaceholderTag is wrong --- Key: WICKET-2580 URL: https://issues.apache.org/jira/browse/WICKET-2580 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4.3, 1.3.7 Reporter: Erik van Oosten The javadoc of Component#setOutputMarkupPlaceholderTag uses the term componentid where it should use markupid. Please update the javadoc from: The tag is of form: lt;componenttag style=display:none; id=componentid/gt;. to The tag is of form: lt;componenttag style=display:none; id=markupid/gt;. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2579) tabbedpanel (and ajaxtabbedpanel) only submit the selected tab. A mode which instead submits all loaded tabs would be helpful.
[ https://issues.apache.org/jira/browse/WICKET-2579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12779472#action_12779472 ] Erik van Oosten commented on WICKET-2579: - This requires an entirely new implementation of TabbedPanel. The current tabbed panel is based on the idea that only the visible tab is rendered. What is needed to implement what you want is to render all tabs to the browser and then only display one of the panels at a time. This can only be done with javascript (another departure of the current TabbedPanel implementation). tabbedpanel (and ajaxtabbedpanel) only submit the selected tab. A mode which instead submits all loaded tabs would be helpful. -- Key: WICKET-2579 URL: https://issues.apache.org/jira/browse/WICKET-2579 Project: Wicket Issue Type: Wish Components: wicket-extensions Affects Versions: 1.4.3 Reporter: Roger Armstrong If I want to split the contents of a form across multiple tabs (for example a user profile form split into basic and advanced settings), there seems to be no way to validate the form properly. The user should be able to fill out, say, first name and last name in the basic tab, then switch to the advanced tab and fill out some settings there, then click the Save button. If the user forgot to fill out a required field on the basic, (say, email address), there's no way to handle this (because the first tab is already gone when you switch to the second tab). I've tried to use an AjaxFormValidatingBehavior on blur of all form components, but this is not a good solution since validation occurs on lost focus instead of when the user clicks the Save button. What I would like would be that the TabbedPanel keeps all visited panels around (but all hidden except the selected tab) so that they are all submitted together. That way, you have lazy loading, but standard submit and validate behavior (at the expense of keeping the loaded panels around). This seems like a fairly standard pattern for using a tabbed panel, so it would seem useful to have it in the standard tab panel instead of everyone having to reinvent it (like at http://www.xaloon.org/blog/advanced-wicket-tabs-with-jquery). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-1355: Attachment: wicket-1355-wicket-1.4.x-autocomplete.patch wicket-1355-wicket-1.3.x-autocomplete.patch Attached 2 patches: - wicket-1355-wicket-1.3.x-autocomplete.patch to be applied in http://svn.apache.org/repos/asf/wicket/branches/wicket-1.3.x/jdk-1.4/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete - wicket-1355-wicket-1.4.x-autocomplete.patch to be applied in http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Assignee: Igor Vaynberg Attachments: wicket-1355-wicket-1.3.x-autocomplete.patch, wicket-1355-wicket-1.4.x-autocomplete.patch, wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12778918#action_12778918 ] Erik van Oosten commented on WICKET-1355: - - wicket-1355-wicket-1.4.x-autocomplete.patch can ALSO be applied in trunk (e.g. in http://svn.apache.org/repos/asf/wicket/trunk/wicket-extensions/src/main/java/org/apache/wicket/extensions/ajax/markup/html/autocomplete) Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Assignee: Igor Vaynberg Attachments: wicket-1355-wicket-1.3.x-autocomplete.patch, wicket-1355-wicket-1.4.x-autocomplete.patch, wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12778940#action_12778940 ] Erik van Oosten commented on WICKET-1355: - The fix is based on the idea that it is very hard to position a div relative to a textfield when that div is added to the document body. Instead the div will be added as a sibling of the textfield. The idea came from colleague Tim Taylor (toolman) who also gave me the initial patch. Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Assignee: Igor Vaynberg Attachments: wicket-1355-wicket-1.3.x-autocomplete.patch, wicket-1355-wicket-1.4.x-autocomplete.patch, wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2395) add MixedParamHybridUrlCodingStrategy
[
https://issues.apache.org/jira/browse/WICKET-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12760086#action_12760086
]
Erik van Oosten commented on WICKET-2395:
-
Igor committed WICKET-2439 earlier. WICKET-2439 also contains this class.
add MixedParamHybridUrlCodingStrategy
-
Key: WICKET-2395
URL: https://issues.apache.org/jira/browse/WICKET-2395
Project: Wicket
Issue Type: New Feature
Affects Versions: 1.4-RC5
Reporter: Vladimir Kovalyuk
Assignee: Juergen Donnerstag
Fix For: 1.4.2
/**
* Apache 2 license.
*/
import java.util.HashSet;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;
import org.apache.wicket.Page;
import org.apache.wicket.PageParameters;
import org.apache.wicket.RequestCycle;
import org.apache.wicket.request.target.coding.HybridUrlCodingStrategy;
import org.apache.wicket.request.target.coding.MixedParamUrlCodingStrategy;
import org.apache.wicket.util.string.AppendingStringBuffer;
import org.apache.wicket.util.value.ValueMap;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
/**
* @see MixedParamUrlCodingStrategy
*
* @author Erik van Oosten
*/
public class MixedParamHybridUrlCodingStrategy extends
HybridUrlCodingStrategy {
private static Logger logger =
LoggerFactory.getLogger(MixedParamHybridUrlCodingStrategy.class);
private final String[] parameterNames;
private boolean ignoreUndeclaredParameters = true;
/**
* Construct.
*
* @param mountPath
*mount path
* @param pageClass
*class of mounted page
* @param redirectOnBookmarkableRequest
*?
* @param parameterNames
*the parameter names (not null)
*/
public MixedParamHybridUrlCodingStrategy(String mountPath, Class?
extends Page pageClass,
boolean redirectOnBookmarkableRequest, String[]
parameterNames) {
super(mountPath, pageClass, redirectOnBookmarkableRequest);
this.parameterNames = parameterNames;
}
/**
* Construct.
*
* @param mountPath
*mount path
* @param pageClass
*class of mounted page
* @param parameterNames
*the parameter names (not null)
*/
public MixedParamHybridUrlCodingStrategy(String mountPath, Class?
extends Page pageClass, String[] parameterNames) {
super(mountPath, pageClass);
this.parameterNames = parameterNames;
}
/** {...@inheritdoc} */
@Override
protected void appendParameters(AppendingStringBuffer url, MapString,
? parameters) {
if (!url.endsWith(/)) {
url.append(/);
}
SetString parameterNamesToAdd = new
HashSetString(parameters.keySet());
// Find index of last specified parameter
boolean foundParameter = false;
int lastSpecifiedParameter = parameterNames.length;
while (lastSpecifiedParameter != 0 !foundParameter) {
foundParameter =
parameters.containsKey(parameterNames[--lastSpecifiedParameter]);
}
if (foundParameter) {
for (int i = 0; i = lastSpecifiedParameter; i++) {
String parameterName = parameterNames[i];
final Object param =
parameters.get(parameterName);
String value = param instanceof String[] ?
((String[]) param)[0] : (String) param;
if (value == null) {
value = ;
}
url.append(urlEncodePathComponent(value)).append(/);
parameterNamesToAdd.remove(parameterName);
}
}
if (!parameterNamesToAdd.isEmpty()) {
boolean first = true;
final Iterator iterator =
parameterNamesToAdd.iterator();
while (iterator.hasNext()) {
url.append(first ? '?' : '');
String parameterName = (String) iterator.next();
final Object param =
parameters.get(parameterName);
String value = param instanceof String[] ?
((String[]) param)[0] : (String) param;
url.append(urlEncodeQueryComponent(parameterName)).append(=).append(urlEncodeQueryComponent(value));
first = false;
[jira] Created: (WICKET-2439) Improve MixedParamUrlCodingStrategy, introduce Hybrid
Improve MixedParamUrlCodingStrategy, introduce Hybrid - Key: WICKET-2439 URL: https://issues.apache.org/jira/browse/WICKET-2439 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4.1 Reporter: Erik van Oosten Fix For: 1.4.2 The MixedParamUrlCodingStrategy can be improved. The current form has the following shortcomings: - it just fails when something is added to the URL, solution: add the option to ignore the added parts (in fact I made this the default) - when something is added to the URL, the message is not very clear, solution: rewrite message and add more information - it does not accept non-String parameter values, solution: use String.valueOf(paramValue) In addition the patch adds a Hybrid variant. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2439) Improve MixedParamUrlCodingStrategy, introduce Hybrid
[ https://issues.apache.org/jira/browse/WICKET-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2439: Attachment: WICKET-2439.patch Please apply to 1.4 branch, possible also to 1.5 branch if that is still applicable. Improve MixedParamUrlCodingStrategy, introduce Hybrid - Key: WICKET-2439 URL: https://issues.apache.org/jira/browse/WICKET-2439 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4.1 Reporter: Erik van Oosten Fix For: 1.4.2 Attachments: WICKET-2439.patch The MixedParamUrlCodingStrategy can be improved. The current form has the following shortcomings: - it just fails when something is added to the URL, solution: add the option to ignore the added parts (in fact I made this the default) - when something is added to the URL, the message is not very clear, solution: rewrite message and add more information - it does not accept non-String parameter values, solution: use String.valueOf(paramValue) In addition the patch adds a Hybrid variant. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2404) Quickstart for 1.4 uses 1.3 dtd in HomePage.html
[ https://issues.apache.org/jira/browse/WICKET-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2404: Attachment: WICKET-2404-1.5.patch WICKET-2404-1.4.patch Patch for Wicket 1.4 (please apply in 1.4 branch) and Wicket 1.5 (please apply in trunk). Quickstart for 1.4 uses 1.3 dtd in HomePage.html Key: WICKET-2404 URL: https://issues.apache.org/jira/browse/WICKET-2404 Project: Wicket Issue Type: Bug Components: wicket-quickstart Affects Versions: 1.4.0 Reporter: Erik van Oosten Priority: Trivial Attachments: WICKET-2404-1.4.patch, WICKET-2404-1.5.patch The generated HomePage.html contains the following header: html xmlns:wicket=http://wicket.apache.org/dtds.data/wicket-xhtml1.3-strict.dtd; That should be: html xmlns:wicket=http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2404) Quickstart for 1.4 uses 1.3 dtd in HomePage.html (with patch)
[ https://issues.apache.org/jira/browse/WICKET-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2404: Summary: Quickstart for 1.4 uses 1.3 dtd in HomePage.html (with patch) (was: Quickstart for 1.4 uses 1.3 dtd in HomePage.html) Quickstart for 1.4 uses 1.3 dtd in HomePage.html (with patch) - Key: WICKET-2404 URL: https://issues.apache.org/jira/browse/WICKET-2404 Project: Wicket Issue Type: Bug Components: wicket-quickstart Affects Versions: 1.4.0 Reporter: Erik van Oosten Priority: Trivial Attachments: WICKET-2404-1.4.patch, WICKET-2404-1.5.patch The generated HomePage.html contains the following header: html xmlns:wicket=http://wicket.apache.org/dtds.data/wicket-xhtml1.3-strict.dtd; That should be: html xmlns:wicket=http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2288) Refactor DefaultPageFactory#constructor
[ https://issues.apache.org/jira/browse/WICKET-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten resolved WICKET-2288. - Resolution: Invalid Seems to be fixed already. Refactor DefaultPageFactory#constructor --- Key: WICKET-2288 URL: https://issues.apache.org/jira/browse/WICKET-2288 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC3 Reporter: Erik van Oosten Priority: Trivial Original Estimate: 0.03h Remaining Estimate: 0.03h Method DefaultPageFactory#constructor should loose the second parameter (argumentType) as it looks up cached Constructor instances without regard of the argument type. Instead the type (always PageParameters.class) should be hard coded in DefaultPageFactory#constructor. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1974) render_to_buffer does not work for absolute URLs
[
https://issues.apache.org/jira/browse/WICKET-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik van Oosten updated WICKET-1974:
Attachment: WICKET-1974.patch
This patch will remove the leading / from the buffer id (when present) in
WebApplication#addBufferedResponse.
mvn test
runs fine.
Please apply to wicket 1.4 branch.
If trunk is still similar, please apply there to.
render_to_buffer does not work for absolute URLs
Key: WICKET-1974
URL: https://issues.apache.org/jira/browse/WICKET-1974
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.4-RC1
Reporter: Erik van Oosten
Attachments: WICKET-1974.patch
After installing a WebRequest instance that makes all URLs absolute,
render_to_buffer does not work anymore. The problem is that WicketFilter
assumes that all URLs are relative (WebFilter#getRelativePath removes the
first char of the URL).
Proposed fixes:
-1- in WebApplication#addBufferedResponse remove the leading / from the
buffer id when present
-2- or alternatively, remove the leading / from the URL (when present) in
WebRequestCycle, just before addBudderedResponse is called
Here is the installed AbsoluteServletWebRequest:
/**
* WebServletRequest that makes bookmarkable links absolute.
* Note: use this only when WickterFilter listens on the root context.
*
* @author Erik van Oosten
*/
public class AbsoluteServletWebRequest extends ServletWebRequest {
public AbsoluteServletWebRequest(HttpServletRequest servletRequest) {
super(servletRequest);
}
@Override
public int getDepthRelativeToWicketHandler() {
return 0;
}
@Override
public String getRelativePathPrefixToWicketHandler() {
return /;
}
@Override
public String getRelativePathPrefixToContextRoot() {
return /;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1974) render_to_buffer does not work for absolute URLs (with patch)
[
https://issues.apache.org/jira/browse/WICKET-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik van Oosten updated WICKET-1974:
Summary: render_to_buffer does not work for absolute URLs (with patch)
(was: render_to_buffer does not work for absolute URLs)
render_to_buffer does not work for absolute URLs (with patch)
-
Key: WICKET-1974
URL: https://issues.apache.org/jira/browse/WICKET-1974
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.4-RC1
Reporter: Erik van Oosten
Attachments: WICKET-1974.patch
After installing a WebRequest instance that makes all URLs absolute,
render_to_buffer does not work anymore. The problem is that WicketFilter
assumes that all URLs are relative (WebFilter#getRelativePath removes the
first char of the URL).
Proposed fixes:
-1- in WebApplication#addBufferedResponse remove the leading / from the
buffer id when present
-2- or alternatively, remove the leading / from the URL (when present) in
WebRequestCycle, just before addBudderedResponse is called
Here is the installed AbsoluteServletWebRequest:
/**
* WebServletRequest that makes bookmarkable links absolute.
* Note: use this only when WickterFilter listens on the root context.
*
* @author Erik van Oosten
*/
public class AbsoluteServletWebRequest extends ServletWebRequest {
public AbsoluteServletWebRequest(HttpServletRequest servletRequest) {
super(servletRequest);
}
@Override
public int getDepthRelativeToWicketHandler() {
return 0;
}
@Override
public String getRelativePathPrefixToWicketHandler() {
return /;
}
@Override
public String getRelativePathPrefixToContextRoot() {
return /;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2404) Quickstart for 1.4 uses 1.3 dtd in HomePage.html
Quickstart for 1.4 uses 1.3 dtd in HomePage.html Key: WICKET-2404 URL: https://issues.apache.org/jira/browse/WICKET-2404 Project: Wicket Issue Type: Bug Components: wicket-quickstart Affects Versions: 1.4.0 Reporter: Erik van Oosten Priority: Trivial The generated HomePage.html contains the following header: html xmlns:wicket=http://wicket.apache.org/dtds.data/wicket-xhtml1.3-strict.dtd; That should be: html xmlns:wicket=http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2332) Open up Markup ctor and MarkupContainer#renderNext
Open up Markup ctor and MarkupContainer#renderNext -- Key: WICKET-2332 URL: https://issues.apache.org/jira/browse/WICKET-2332 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC4 Reporter: Erik van Oosten Fix For: 1.4-RC5 -1- Change org.apache.wicket.markup.Markup#Markup(): from default to public -2- Change org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (it stays final) Rationale from the dev e-mail list: Erik van Oosten wrote: --- Hi, I am writing a Swing like layout manager (with MIG layout manager's API as inspiration). The layout manager will generate HTML, but also has the ability to override this with HTML defined by the user. I have a prototype that does this. It takes elements from the current Markupstream, adds the elements that are missing, and then some more to facilitate the layouting (well the last step is next on my todo list). These elements are then put in a new markupstream that is used to drive onComponentTagBody of the layout component. For this to work I had to open up 2 things: - org.apache.wicket.markup.Markup#Markup(): from default to public I could have written my own implementation of IMarkup, but that seems a bit overkill as I need exactly what is in Markup. - org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (don't care if it stays final) My onComponentTagBody implementation is loosely based on method org.apache.wicket.MarkupContainer#renderAssociatedMarkup(String,String). One of the methods I need to call to render children seems to be renderNext. Could these two be opened up? --- Juergen Donnerstag wrote: --- I don't mind open up both, as long as renderNext() stays final and we tag it as THIS IS WICKET INTERNAL. --- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2332) Open up Markup ctor and MarkupContainer#renderNext
[ https://issues.apache.org/jira/browse/WICKET-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2332: Attachment: WICKET-2332.patch Please apply path in trunk. Open up Markup ctor and MarkupContainer#renderNext -- Key: WICKET-2332 URL: https://issues.apache.org/jira/browse/WICKET-2332 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC4 Reporter: Erik van Oosten Fix For: 1.4-RC5 Attachments: WICKET-2332.patch -1- Change org.apache.wicket.markup.Markup#Markup(): from default to public -2- Change org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (it stays final) Rationale from the dev e-mail list: Erik van Oosten wrote: --- Hi, I am writing a Swing like layout manager (with MIG layout manager's API as inspiration). The layout manager will generate HTML, but also has the ability to override this with HTML defined by the user. I have a prototype that does this. It takes elements from the current Markupstream, adds the elements that are missing, and then some more to facilitate the layouting (well the last step is next on my todo list). These elements are then put in a new markupstream that is used to drive onComponentTagBody of the layout component. For this to work I had to open up 2 things: - org.apache.wicket.markup.Markup#Markup(): from default to public I could have written my own implementation of IMarkup, but that seems a bit overkill as I need exactly what is in Markup. - org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (don't care if it stays final) My onComponentTagBody implementation is loosely based on method org.apache.wicket.MarkupContainer#renderAssociatedMarkup(String,String). One of the methods I need to call to render children seems to be renderNext. Could these two be opened up? --- Juergen Donnerstag wrote: --- I don't mind open up both, as long as renderNext() stays final and we tag it as THIS IS WICKET INTERNAL. --- -- 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-2332) Open up Markup ctor and MarkupContainer#renderNext
[ https://issues.apache.org/jira/browse/WICKET-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12721107#action_12721107 ] Erik van Oosten edited comment on WICKET-2332 at 6/18/09 12:25 AM: --- Please apply patch in trunk. was (Author: erikvanoosten): Please apply path in trunk. Open up Markup ctor and MarkupContainer#renderNext -- Key: WICKET-2332 URL: https://issues.apache.org/jira/browse/WICKET-2332 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC4 Reporter: Erik van Oosten Fix For: 1.4-RC5 Attachments: WICKET-2332.patch -1- Change org.apache.wicket.markup.Markup#Markup(): from default to public -2- Change org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (it stays final) Rationale from the dev e-mail list: Erik van Oosten wrote: --- Hi, I am writing a Swing like layout manager (with MIG layout manager's API as inspiration). The layout manager will generate HTML, but also has the ability to override this with HTML defined by the user. I have a prototype that does this. It takes elements from the current Markupstream, adds the elements that are missing, and then some more to facilitate the layouting (well the last step is next on my todo list). These elements are then put in a new markupstream that is used to drive onComponentTagBody of the layout component. For this to work I had to open up 2 things: - org.apache.wicket.markup.Markup#Markup(): from default to public I could have written my own implementation of IMarkup, but that seems a bit overkill as I need exactly what is in Markup. - org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (don't care if it stays final) My onComponentTagBody implementation is loosely based on method org.apache.wicket.MarkupContainer#renderAssociatedMarkup(String,String). One of the methods I need to call to render children seems to be renderNext. Could these two be opened up? --- Juergen Donnerstag wrote: --- I don't mind open up both, as long as renderNext() stays final and we tag it as THIS IS WICKET INTERNAL. --- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2332) Open up Markup ctor and MarkupContainer#renderNext
[ https://issues.apache.org/jira/browse/WICKET-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2332: Fix Version/s: (was: 1.4-RC5) 1.4-RC6 Open up Markup ctor and MarkupContainer#renderNext -- Key: WICKET-2332 URL: https://issues.apache.org/jira/browse/WICKET-2332 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC4 Reporter: Erik van Oosten Fix For: 1.4-RC6 Attachments: WICKET-2332.patch -1- Change org.apache.wicket.markup.Markup#Markup(): from default to public -2- Change org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (it stays final) Rationale from the dev e-mail list: Erik van Oosten wrote: --- Hi, I am writing a Swing like layout manager (with MIG layout manager's API as inspiration). The layout manager will generate HTML, but also has the ability to override this with HTML defined by the user. I have a prototype that does this. It takes elements from the current Markupstream, adds the elements that are missing, and then some more to facilitate the layouting (well the last step is next on my todo list). These elements are then put in a new markupstream that is used to drive onComponentTagBody of the layout component. For this to work I had to open up 2 things: - org.apache.wicket.markup.Markup#Markup(): from default to public I could have written my own implementation of IMarkup, but that seems a bit overkill as I need exactly what is in Markup. - org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (don't care if it stays final) My onComponentTagBody implementation is loosely based on method org.apache.wicket.MarkupContainer#renderAssociatedMarkup(String,String). One of the methods I need to call to render children seems to be renderNext. Could these two be opened up? --- Juergen Donnerstag wrote: --- I don't mind open up both, as long as renderNext() stays final and we tag it as THIS IS WICKET INTERNAL. --- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2332) Open up Markup ctor and MarkupContainer#renderNext
[ https://issues.apache.org/jira/browse/WICKET-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12721143#action_12721143 ] Erik van Oosten commented on WICKET-2332: - Hmm, perhaps org.apache.wicket.markup.Markup.makeImmutable() should be made public as well. Open up Markup ctor and MarkupContainer#renderNext -- Key: WICKET-2332 URL: https://issues.apache.org/jira/browse/WICKET-2332 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC4 Reporter: Erik van Oosten Fix For: 1.4-RC6 Attachments: WICKET-2332.patch -1- Change org.apache.wicket.markup.Markup#Markup(): from default to public -2- Change org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (it stays final) Rationale from the dev e-mail list: Erik van Oosten wrote: --- Hi, I am writing a Swing like layout manager (with MIG layout manager's API as inspiration). The layout manager will generate HTML, but also has the ability to override this with HTML defined by the user. I have a prototype that does this. It takes elements from the current Markupstream, adds the elements that are missing, and then some more to facilitate the layouting (well the last step is next on my todo list). These elements are then put in a new markupstream that is used to drive onComponentTagBody of the layout component. For this to work I had to open up 2 things: - org.apache.wicket.markup.Markup#Markup(): from default to public I could have written my own implementation of IMarkup, but that seems a bit overkill as I need exactly what is in Markup. - org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (don't care if it stays final) My onComponentTagBody implementation is loosely based on method org.apache.wicket.MarkupContainer#renderAssociatedMarkup(String,String). One of the methods I need to call to render children seems to be renderNext. Could these two be opened up? --- Juergen Donnerstag wrote: --- I don't mind open up both, as long as renderNext() stays final and we tag it as THIS IS WICKET INTERNAL. --- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2332) Open up Markup ctor and MarkupContainer#renderNext
[ https://issues.apache.org/jira/browse/WICKET-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2332: Attachment: WICKET-2332-2.patch Second patch also makes org.apache.wicket.markup.Markup.makeImmutable() public. Again, please apply in trunk. Open up Markup ctor and MarkupContainer#renderNext -- Key: WICKET-2332 URL: https://issues.apache.org/jira/browse/WICKET-2332 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC4 Reporter: Erik van Oosten Fix For: 1.4-RC6 Attachments: WICKET-2332-2.patch, WICKET-2332.patch -1- Change org.apache.wicket.markup.Markup#Markup(): from default to public -2- Change org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (it stays final) Rationale from the dev e-mail list: Erik van Oosten wrote: --- Hi, I am writing a Swing like layout manager (with MIG layout manager's API as inspiration). The layout manager will generate HTML, but also has the ability to override this with HTML defined by the user. I have a prototype that does this. It takes elements from the current Markupstream, adds the elements that are missing, and then some more to facilitate the layouting (well the last step is next on my todo list). These elements are then put in a new markupstream that is used to drive onComponentTagBody of the layout component. For this to work I had to open up 2 things: - org.apache.wicket.markup.Markup#Markup(): from default to public I could have written my own implementation of IMarkup, but that seems a bit overkill as I need exactly what is in Markup. - org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (don't care if it stays final) My onComponentTagBody implementation is loosely based on method org.apache.wicket.MarkupContainer#renderAssociatedMarkup(String,String). One of the methods I need to call to render children seems to be renderNext. Could these two be opened up? --- Juergen Donnerstag wrote: --- I don't mind open up both, as long as renderNext() stays final and we tag it as THIS IS WICKET INTERNAL. --- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2292) TabbedPanel uses too much generics (revert Wicket-2135)
TabbedPanel uses too much generics (revert Wicket-2135) --- Key: WICKET-2292 URL: https://issues.apache.org/jira/browse/WICKET-2292 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-RC3 Reporter: Erik van Oosten Fix For: 1.4-RC5 Please revert Wicket-2135. By declaring the list of tabs as List? extends ITab you are saying that the list contains elements with some super type that is a subtype of ITab. Having this type there is no way of knowing which exact supertype that is, just that it is a subclass of ITab. The result is that you can only add null to the list. Of course this is non-sense; TabbedPanel uses ITab and not some unknown subclass thereof. To demonstrate: right now you can not do: ITab tab = ...; tabbedPanel.getTabs().add(tab); To properly solve Wicket-2135, the user should cast his/her list to ListITab or just create a list of that type in the first place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2292) TabbedPanel uses too much generics (revert WICKET-2135)
[ https://issues.apache.org/jira/browse/WICKET-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2292: Description: Please revert WICKET-2135. By declaring the list of tabs as List? extends ITab you are saying that the list contains elements with some super type that is a subtype of ITab. Having this type there is no way of knowing which exact supertype that is, just that it is a subclass of ITab. The result is that you can only add null to the list. Of course this is non-sense; TabbedPanel uses ITab and not some unknown subclass thereof. To demonstrate: right now you can not do: ITab tab = ...; tabbedPanel.getTabs().add(tab); To properly solve WICKET-2135, the user should cast his/her list to ListITab or just create a list of that type in the first place. was: Please revert Wicket-2135. By declaring the list of tabs as List? extends ITab you are saying that the list contains elements with some super type that is a subtype of ITab. Having this type there is no way of knowing which exact supertype that is, just that it is a subclass of ITab. The result is that you can only add null to the list. Of course this is non-sense; TabbedPanel uses ITab and not some unknown subclass thereof. To demonstrate: right now you can not do: ITab tab = ...; tabbedPanel.getTabs().add(tab); To properly solve Wicket-2135, the user should cast his/her list to ListITab or just create a list of that type in the first place. Summary: TabbedPanel uses too much generics (revert WICKET-2135) (was: TabbedPanel uses too much generics (revert Wicket-2135)) TabbedPanel uses too much generics (revert WICKET-2135) --- Key: WICKET-2292 URL: https://issues.apache.org/jira/browse/WICKET-2292 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-RC3 Reporter: Erik van Oosten Fix For: 1.4-RC5 Please revert WICKET-2135. By declaring the list of tabs as List? extends ITab you are saying that the list contains elements with some super type that is a subtype of ITab. Having this type there is no way of knowing which exact supertype that is, just that it is a subclass of ITab. The result is that you can only add null to the list. Of course this is non-sense; TabbedPanel uses ITab and not some unknown subclass thereof. To demonstrate: right now you can not do: ITab tab = ...; tabbedPanel.getTabs().add(tab); To properly solve WICKET-2135, the user should cast his/her list to ListITab or just create a list of that type in the first place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2292) TabbedPanel uses too much generics (revert WICKET-2153)
[ https://issues.apache.org/jira/browse/WICKET-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2292: Description: Please revert WICKET-2153. By declaring the list of tabs as List? extends ITab you are saying that the list contains elements with some super type that is a subtype of ITab. Having this type there is no way of knowing which exact supertype that is, just that it is a subclass of ITab. The result is that you can only add null to the list. Of course this is non-sense; TabbedPanel uses ITab and not some unknown subclass thereof. To demonstrate: right now you can not do: ITab tab = ...; tabbedPanel.getTabs().add(tab); To properly solve WICKET-2153, the user should cast his/her list to ListITab or just create a list of that type in the first place. was: Please revert WICKET-2135. By declaring the list of tabs as List? extends ITab you are saying that the list contains elements with some super type that is a subtype of ITab. Having this type there is no way of knowing which exact supertype that is, just that it is a subclass of ITab. The result is that you can only add null to the list. Of course this is non-sense; TabbedPanel uses ITab and not some unknown subclass thereof. To demonstrate: right now you can not do: ITab tab = ...; tabbedPanel.getTabs().add(tab); To properly solve WICKET-2135, the user should cast his/her list to ListITab or just create a list of that type in the first place. Summary: TabbedPanel uses too much generics (revert WICKET-2153) (was: TabbedPanel uses too much generics (revert WICKET-2135)) TabbedPanel uses too much generics (revert WICKET-2153) --- Key: WICKET-2292 URL: https://issues.apache.org/jira/browse/WICKET-2292 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-RC3 Reporter: Erik van Oosten Fix For: 1.4-RC5 Please revert WICKET-2153. By declaring the list of tabs as List? extends ITab you are saying that the list contains elements with some super type that is a subtype of ITab. Having this type there is no way of knowing which exact supertype that is, just that it is a subclass of ITab. The result is that you can only add null to the list. Of course this is non-sense; TabbedPanel uses ITab and not some unknown subclass thereof. To demonstrate: right now you can not do: ITab tab = ...; tabbedPanel.getTabs().add(tab); To properly solve WICKET-2153, the user should cast his/her list to ListITab or just create a list of that type in the first place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2288) Refactor DefaultPageFactory#constructor
[ https://issues.apache.org/jira/browse/WICKET-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712425#action_12712425 ] Erik van Oosten commented on WICKET-2288: - BTW, the default ctor instances could be cached as well, but that is definitely outside the scope of this issue. Refactor DefaultPageFactory#constructor --- Key: WICKET-2288 URL: https://issues.apache.org/jira/browse/WICKET-2288 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC3 Reporter: Erik van Oosten Priority: Trivial Original Estimate: 0.03h Remaining Estimate: 0.03h Method DefaultPageFactory#constructor should loose the second parameter (argumentType) as it looks up cached Constructor instances without regard of the argument type. Instead the type (always PageParameters.class) should be hard coded in DefaultPageFactory#constructor. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2040) Wrong log message text in RequestCycle#prepare
Wrong log message text in RequestCycle#prepare -- Key: WICKET-2040 URL: https://issues.apache.org/jira/browse/WICKET-2040 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-RC1 Reporter: Erik van Oosten Priority: Trivial In RequestCycle#prepare it says: log.error(Exception occurred during onEndRequest of the SessionStore, e); This should be: log.error(Exception occurred during onBeginRequest of the SessionStore, e); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2025) isVisible should not be called after detach
isVisible should not be called after detach --- Key: WICKET-2025 URL: https://issues.apache.org/jira/browse/WICKET-2025 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-RC1 Reporter: Erik van Oosten I think isVisible should not be called after detach to prevent model reloads. I found one call to isVisible after detach in method ComponentRequestTarget#respond(RequestCycle). That method initiates a detach and then calls page.endComponentRender. This leads to a call to Page#checkRendering which calls isVisibleInHierarchy() and from there isVisible(). Method checkRendering only does something when the debug setting 'componentUseCheck' is enabled (which according to the javadoc is true by default). Short term workaround: set debug setting 'componentUseCheck' to false. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2025) isVisible should not be called after detach
[ https://issues.apache.org/jira/browse/WICKET-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12664533#action_12664533 ] Erik van Oosten commented on WICKET-2025: - In that case the javadoc of IDebugSettings needs an update. It does not change the importance of this issue. isVisible should not be called after detach --- Key: WICKET-2025 URL: https://issues.apache.org/jira/browse/WICKET-2025 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-RC1 Reporter: Erik van Oosten I think isVisible should not be called after detach to prevent model reloads. I found one call to isVisible after detach in method ComponentRequestTarget#respond(RequestCycle). That method initiates a detach and then calls page.endComponentRender. This leads to a call to Page#checkRendering which calls isVisibleInHierarchy() and from there isVisible(). Method checkRendering only does something when the debug setting 'componentUseCheck' is enabled (which according to the javadoc is true by default). Short term workaround: set debug setting 'componentUseCheck' to false. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1973) Messages lost upon session failover with redirect_to_buffer
Messages lost upon session failover with redirect_to_buffer --- Key: WICKET-1973 URL: https://issues.apache.org/jira/browse/WICKET-1973 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-RC1 Reporter: Erik van Oosten Using the redirect_to_buffer render strategy, messages in the session get cleared after the render. If the redirected request comes in at another node, the buffer is not found and the page is re-rendered. In this case the messages are no longer available. See the javadoc of WebApplication#popBufferedResponse(String,String). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1974) render_to_buffer does not work for absolute URLs
[
https://issues.apache.org/jira/browse/WICKET-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik van Oosten updated WICKET-1974:
Component/s: (was: wicket-auth-roles)
render_to_buffer does not work for absolute URLs
Key: WICKET-1974
URL: https://issues.apache.org/jira/browse/WICKET-1974
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.4-RC1
Reporter: Erik van Oosten
After installing a WebRequest instance that makes all URLs absolute,
render_to_buffer does not work anymore. The problem is that WicketFilter
assumes that all URLs are relative (WebFilter#getRelativePath removes the
first char of the URL).
Proposed fixes:
-1- in WebApplication#addBufferedResponse remove the leading / from the
buffer id when present
-2- or alternatively, remove the leading / from the URL (when present) in
WebRequestCycle, just before addBudderedResponse is called
Here is the installed AbsoluteServletWebRequest:
/**
* WebServletRequest that makes bookmarkable links absolute.
*
* @author Erik van Oosten
*/
public class AbsoluteServletWebRequest extends ServletWebRequest {
public AbsoluteServletWebRequest(HttpServletRequest servletRequest) {
super(servletRequest);
}
@Override
public int getDepthRelativeToWicketHandler() {
return 0;
}
@Override
public String getRelativePathPrefixToWicketHandler() {
return /;
}
@Override
public String getRelativePathPrefixToContextRoot() {
return /;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1974) render_to_buffer does not work for absolute URLs
render_to_buffer does not work for absolute URLs
Key: WICKET-1974
URL: https://issues.apache.org/jira/browse/WICKET-1974
Project: Wicket
Issue Type: Improvement
Components: wicket, wicket-auth-roles
Affects Versions: 1.4-RC1
Reporter: Erik van Oosten
After installing a WebRequest instance that makes all URLs absolute,
render_to_buffer does not work anymore. The problem is that WicketFilter
assumes that all URLs are relative (WebFilter#getRelativePath removes the first
char of the URL).
Proposed fixes:
-1- in WebApplication#addBufferedResponse remove the leading / from the
buffer id when present
-2- or alternatively, remove the leading / from the URL (when present) in
WebRequestCycle, just before addBudderedResponse is called
Here is the installed AbsoluteServletWebRequest:
/**
* WebServletRequest that makes bookmarkable links absolute.
*
* @author Erik van Oosten
*/
public class AbsoluteServletWebRequest extends ServletWebRequest {
public AbsoluteServletWebRequest(HttpServletRequest servletRequest) {
super(servletRequest);
}
@Override
public int getDepthRelativeToWicketHandler() {
return 0;
}
@Override
public String getRelativePathPrefixToWicketHandler() {
return /;
}
@Override
public String getRelativePathPrefixToContextRoot() {
return /;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1974) render_to_buffer does not work for absolute URLs
[
https://issues.apache.org/jira/browse/WICKET-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik van Oosten updated WICKET-1974:
Description:
After installing a WebRequest instance that makes all URLs absolute,
render_to_buffer does not work anymore. The problem is that WicketFilter
assumes that all URLs are relative (WebFilter#getRelativePath removes the first
char of the URL).
Proposed fixes:
-1- in WebApplication#addBufferedResponse remove the leading / from the
buffer id when present
-2- or alternatively, remove the leading / from the URL (when present) in
WebRequestCycle, just before addBudderedResponse is called
Here is the installed AbsoluteServletWebRequest:
/**
* WebServletRequest that makes bookmarkable links absolute.
* Note: use this only when WickterFilter listens on the root context.
*
* @author Erik van Oosten
*/
public class AbsoluteServletWebRequest extends ServletWebRequest {
public AbsoluteServletWebRequest(HttpServletRequest servletRequest) {
super(servletRequest);
}
@Override
public int getDepthRelativeToWicketHandler() {
return 0;
}
@Override
public String getRelativePathPrefixToWicketHandler() {
return /;
}
@Override
public String getRelativePathPrefixToContextRoot() {
return /;
}
}
was:
After installing a WebRequest instance that makes all URLs absolute,
render_to_buffer does not work anymore. The problem is that WicketFilter
assumes that all URLs are relative (WebFilter#getRelativePath removes the first
char of the URL).
Proposed fixes:
-1- in WebApplication#addBufferedResponse remove the leading / from the
buffer id when present
-2- or alternatively, remove the leading / from the URL (when present) in
WebRequestCycle, just before addBudderedResponse is called
Here is the installed AbsoluteServletWebRequest:
/**
* WebServletRequest that makes bookmarkable links absolute.
*
* @author Erik van Oosten
*/
public class AbsoluteServletWebRequest extends ServletWebRequest {
public AbsoluteServletWebRequest(HttpServletRequest servletRequest) {
super(servletRequest);
}
@Override
public int getDepthRelativeToWicketHandler() {
return 0;
}
@Override
public String getRelativePathPrefixToWicketHandler() {
return /;
}
@Override
public String getRelativePathPrefixToContextRoot() {
return /;
}
}
render_to_buffer does not work for absolute URLs
Key: WICKET-1974
URL: https://issues.apache.org/jira/browse/WICKET-1974
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.4-RC1
Reporter: Erik van Oosten
After installing a WebRequest instance that makes all URLs absolute,
render_to_buffer does not work anymore. The problem is that WicketFilter
assumes that all URLs are relative (WebFilter#getRelativePath removes the
first char of the URL).
Proposed fixes:
-1- in WebApplication#addBufferedResponse remove the leading / from the
buffer id when present
-2- or alternatively, remove the leading / from the URL (when present) in
WebRequestCycle, just before addBudderedResponse is called
Here is the installed AbsoluteServletWebRequest:
/**
* WebServletRequest that makes bookmarkable links absolute.
* Note: use this only when WickterFilter listens on the root context.
*
* @author Erik van Oosten
*/
public class AbsoluteServletWebRequest extends ServletWebRequest {
public AbsoluteServletWebRequest(HttpServletRequest servletRequest) {
super(servletRequest);
}
@Override
public int getDepthRelativeToWicketHandler() {
return 0;
}
@Override
public String getRelativePathPrefixToWicketHandler() {
return /;
}
@Override
public String getRelativePathPrefixToContextRoot() {
return /;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1878) ExternalLink should have title field
[
https://issues.apache.org/jira/browse/WICKET-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12643227#action_12643227
]
Erik van Oosten commented on WICKET-1878:
-
Proposed solution: Won't fix.
Wicket should stay clean and mean. Adding these kinds of options all over the
place won't help achive this goal.
Here is a custom component that reaches the comitters goal with a custom
component.
public abstract class TitledLink extends Link {
public TitledLink(String id, String title) {
this(id, new ModelString(title));
}
public TitledLink(String id, IModelString titleModel) {
super(id);
add(new AttributeModifier(title, true, titleModel));
}
}
ExternalLink should have title field
Key: WICKET-1878
URL: https://issues.apache.org/jira/browse/WICKET-1878
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.3.4, 1.4-M3
Reporter: Steve Swinsburg
The ExternalLink component should either by default have a title field, or
have another constructor that takes the title as a paremeter. Currently this
is only achieved by using AttributeAppender and setting the title attribute
onto the link.
eg current:
ExternalLink emailLink = new ExternalLink(mailToLink,new Model(mailto:; +
emailAddress),new Model(emailAddress));
emailLink.add(new AttributeAppender(title, new Model(emailAddress), ));
I propose the following constructor:
ExternalLink(java.lang.String id, java.lang.String href, java.lang.String
label, java.lang.String title)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635118#action_12635118 ] Erik van Oosten commented on WICKET-1355: - Okay. I'll try. I'll be a JAOO so it has to wait till Thursday though. Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Assignee: Igor Vaynberg Fix For: 1.3.5 Attachments: wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1746) gecko: ajax javascript reference rendering problem
[
https://issues.apache.org/jira/browse/WICKET-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12634772#action_12634772
]
Erik van Oosten commented on WICKET-1746:
-
As a workaround, add the following behavior to your page (javascript based on
wicket 1.3.4):
private static class WicketAjaxRelativePathFixBehaviour extends AbstractBehavior
{
private static final long serialVersionUID = 1L;
@Override
public void renderHead(IHeaderResponse response)
{
String script = if (Wicket Wicket.Ajax
Wicket.Ajax.Request) {+
Wicket.Ajax.Request.prototype.doGet =
function() { +
if (this.precondition()) { +
this.transport =
Wicket.Ajax.getTransport(); +
var url = this.createUrl(); +
this.log(\GET\, url); +
Wicket.Ajax.invokePreCallHandlers(); +
var t = this.transport; +
if (t != null) { +
t.open(\GET\, url,
this.async); +
t.onreadystatechange =
this.stateChangeCallback.bind(this); +
/*set a special flag to
allow server distinguish between ajax and non-ajax requests*/ +
t.setRequestHeader(\Wicket-Ajax\, \true\); +
t.setRequestHeader(\Wicket-FocusedElementId\, Wicket.Focus.lastFocusId ||
\\); +
t.setRequestHeader(\Accept\, \text/xml\); +
t.send(null); +
return true; +
} else { +
this.failure(); +
return false; +
} +
} else { +
Wicket.Log.info(\Ajax GET
stopped because of precondition check, url:\ + this.url); +
this.done(); +
return true; +
} +
}};
response.renderOnDomReadyJavascript(script);
}
}
gecko: ajax javascript reference rendering problem
--
Key: WICKET-1746
URL: https://issues.apache.org/jira/browse/WICKET-1746
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.4-M2
Reporter: Jan Loose
Assignee: Matej Knopp
Fix For: 1.3.5, 1.4-M4
Hi,
i tried render the javascript as:
public void renderHead(IHeaderResponse response) {
response.renderJavascriptReference(contextPath + js/test.js);
}
The test.js is in webapp/js/test.js (out of classpath). All works greatly in
Opera but in FF (gecko) is there a problem in wicket-ajax.js (the code is
form trunk version):
836: if (Wicket.Browser.isGecko()) {
837: var href = document.location.href;
838: var lastIndexOf = href.lastIndexOf('/');
839: if (lastIndexOf 0)
840: {
841: url = href.substring(0,lastIndexOf+1) + url;
842:}
843:}
Why is there this fix/workaround? This works only for relative path but for
absolute is this code broken.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1349) Wicket Ajax response generates a ^ character in the javascript code
[
https://issues.apache.org/jira/browse/WICKET-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12629479#action_12629479
]
Erik van Oosten commented on WICKET-1349:
-
Note, the code above will also require changes in the ajax code. The ajax code
currently only retrieves the first text node for every type of response, with
the escaping from above it should get all text nodes and concatenate them (like
a XPath query would do). Actually, you should *always* get all text nodes as
most XML DOM parsers (if not, all) do not guarantee that they put all
consecutive text in a single text node.
The fix above is not complete, it should also give back another encoding string
(method getEncodingName()).
Wicket Ajax response generates a ^ character in the javascript code
-
Key: WICKET-1349
URL: https://issues.apache.org/jira/browse/WICKET-1349
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.1
Environment: IE6 and IE7
Reporter: Wen Tong Allan
Assignee: Igor Vaynberg
I have a page that uses AjaxFallbackDefaultDataTable (using
SortableDataProvider ). The markup contains user-define javascript that I
added. When I try to do some action (delete row) with the table, the page
doesn't refresh in IE6 and IE7. I checked the Wicket Ajax Debugger and it
displays:
ERROR: Error while parsing response: Object required
INFO: Invoking post-call handler(s)...
INFO: invoking failure handler(s)...
I also noticed that the user-define javascript that was returned by the ajax
debugger was appended by ^. (See javascript below):
// enable disable button.
function setButtonState() {
var formObj =
eval(document.getElementsByName(contactListForm)[0]^);
var state = anyChecked(formObj);
document.getElementsByName(deleteContactsButton)[0]^.disabled = !state;
document.getElementsByName(newContactGroupButton)[0]^.disabled = !state;
document.getElementsByName(newEventButton)[0]^.disabled
= !state;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-847) setResponsePage redirects to wrong url
[
https://issues.apache.org/jira/browse/WICKET-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628320#action_12628320
]
Erik van Oosten commented on WICKET-847:
I got bitten by this as well (with 1.4-m3).
The failing combination is: Tomcat and IE (6 or 7).
Firefox correctly interprets the ./ as so its okay to use Firefox + Tomcat.
Jetty converts ./ to , so its okay to use any borwser on Jetty.
My patch is:
In BookmarkablePageRequestTarget:
public void respond(RequestCycle requestCycle)
{
if (pageClassRef != null pageClassRef.get() != null)
{
if (requestCycle.isRedirect())
{
IRequestCycleProcessor processor =
requestCycle.getProcessor();
String redirectUrl =
processor.getRequestCodingStrategy()
.encode(requestCycle, this)
.toString();
// START OF PATCH
if (redirectUrl.startsWith(./)) {
redirectUrl = redirectUrl.substring(2);
}
// END OF PATCH
requestCycle.getResponse().redirect(redirectUrl);
}
else
{
// Let the page render itself
getPage(requestCycle).renderPage();
}
}
}
And in RedirectRequestTarget:
public void respond(RequestCycle requestCycle)
{
Response response = requestCycle.getResponse();
response.reset();
if (redirectUrl.startsWith(/))
{
RequestContext rc = RequestContext.get();
if (rc.isPortletRequest()
((PortletRequestContext)rc).isEmbedded())
{
response.redirect(redirectUrl);
}
else
{
String location = RequestCycle.get()
.getRequest()
.getRelativePathPrefixToContextRoot() +
this.redirectUrl.substring(1);
// START OF PATCH
if (location.startsWith(./)) {
location = location.substring(2);
}
// END OF PATCH
response.redirect(location);
}
}
else if (redirectUrl.startsWith(http://;) ||
redirectUrl.startsWith(https://;))
{
response.redirect(redirectUrl);
}
else
{
response.redirect(RequestCycle.get()
.getRequest()
.getRelativePathPrefixToWicketHandler() +
redirectUrl);
}
}
setResponsePage redirects to wrong url
--
Key: WICKET-847
URL: https://issues.apache.org/jira/browse/WICKET-847
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.0-beta2
Reporter: Andrew Klochkov
Assignee: Alastair Maw
Fix For: 1.3.5
Attachments: wicket-quickstart.tar.gz
When I do setResponsePage(MyHomePage.class) IE tries to show me
my.site.com/./ url and gets 404 response.
Firefox just shows my.site.com without any troubles. I'm using wicket
1.3-beta2 and WicketFilter mapped to /*.
It's being reproduced under tomcat only, jetty works fine. My tomcat version
is 5.5.17.
Quickstart project which reproduces the bug is attached.
--
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-847) setResponsePage redirects to wrong url
[
https://issues.apache.org/jira/browse/WICKET-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628320#action_12628320
]
erikvanoosten edited comment on WICKET-847 at 9/4/08 5:03 AM:
I got bitten by this as well (with 1.4-m3).
The failing combination is: Tomcat and IE (6 or 7).
Firefox correctly interprets the ./ as so its okay to use Firefox + Tomcat.
Jetty converts ./ to , so its okay to use any borwser on Jetty.
My workaround was to patch these two Wicket core files (I can confirm it works):
BookmarkablePageRequestTarget:
---8--
public void respond(RequestCycle requestCycle)
{
if (pageClassRef != null pageClassRef.get() != null)
{
if (requestCycle.isRedirect())
{
IRequestCycleProcessor processor =
requestCycle.getProcessor();
String redirectUrl =
processor.getRequestCodingStrategy()
.encode(requestCycle, this)
.toString();
// START OF PATCH
if (redirectUrl.startsWith(./)) {
redirectUrl = redirectUrl.substring(2);
}
// END OF PATCH
requestCycle.getResponse().redirect(redirectUrl);
}
else
{
// Let the page render itself
getPage(requestCycle).renderPage();
}
}
}
---8--
RedirectRequestTarget:
---8--
public void respond(RequestCycle requestCycle)
{
Response response = requestCycle.getResponse();
response.reset();
if (redirectUrl.startsWith(/))
{
RequestContext rc = RequestContext.get();
if (rc.isPortletRequest()
((PortletRequestContext)rc).isEmbedded())
{
response.redirect(redirectUrl);
}
else
{
String location = RequestCycle.get()
.getRequest()
.getRelativePathPrefixToContextRoot() +
this.redirectUrl.substring(1);
// START OF PATCH
if (location.startsWith(./)) {
location = location.substring(2);
}
// END OF PATCH
response.redirect(location);
}
}
else if (redirectUrl.startsWith(http://;) ||
redirectUrl.startsWith(https://;))
{
response.redirect(redirectUrl);
}
else
{
response.redirect(RequestCycle.get()
.getRequest()
.getRelativePathPrefixToWicketHandler() +
redirectUrl);
}
}
---8--
was (Author: erikvanoosten):
I got bitten by this as well (with 1.4-m3).
The failing combination is: Tomcat and IE (6 or 7).
Firefox correctly interprets the ./ as so its okay to use Firefox + Tomcat.
Jetty converts ./ to , so its okay to use any borwser on Jetty.
My patch is:
In BookmarkablePageRequestTarget:
public void respond(RequestCycle requestCycle)
{
if (pageClassRef != null pageClassRef.get() != null)
{
if (requestCycle.isRedirect())
{
IRequestCycleProcessor processor =
requestCycle.getProcessor();
String redirectUrl =
processor.getRequestCodingStrategy()
.encode(requestCycle, this)
.toString();
// START OF PATCH
if (redirectUrl.startsWith(./)) {
redirectUrl = redirectUrl.substring(2);
}
// END OF PATCH
requestCycle.getResponse().redirect(redirectUrl);
}
else
{
// Let the page render itself
getPage(requestCycle).renderPage();
}
}
}
And in RedirectRequestTarget:
public void respond(RequestCycle requestCycle)
{
Response response = requestCycle.getResponse();
response.reset();
if (redirectUrl.startsWith(/))
{
[jira] Issue Comment Edited: (WICKET-847) setResponsePage redirects to wrong url
[
https://issues.apache.org/jira/browse/WICKET-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628320#action_12628320
]
erikvanoosten edited comment on WICKET-847 at 9/4/08 5:03 AM:
I got bitten by this as well (with 1.4-m3).
The failing combination is: Tomcat and IE (6 or 7).
Firefox correctly interprets the ./ as so its okay to use Firefox + Tomcat.
Jetty converts ./ to , so its okay to use any borwser on Jetty.
My workaround was to patch these two Wicket core files (I can confirm it works
when redirecting to the home page):
BookmarkablePageRequestTarget:
---8--
public void respond(RequestCycle requestCycle)
{
if (pageClassRef != null pageClassRef.get() != null)
{
if (requestCycle.isRedirect())
{
IRequestCycleProcessor processor =
requestCycle.getProcessor();
String redirectUrl =
processor.getRequestCodingStrategy()
.encode(requestCycle, this)
.toString();
// START OF PATCH
if (redirectUrl.startsWith(./)) {
redirectUrl = redirectUrl.substring(2);
}
// END OF PATCH
requestCycle.getResponse().redirect(redirectUrl);
}
else
{
// Let the page render itself
getPage(requestCycle).renderPage();
}
}
}
---8--
RedirectRequestTarget:
---8--
public void respond(RequestCycle requestCycle)
{
Response response = requestCycle.getResponse();
response.reset();
if (redirectUrl.startsWith(/))
{
RequestContext rc = RequestContext.get();
if (rc.isPortletRequest()
((PortletRequestContext)rc).isEmbedded())
{
response.redirect(redirectUrl);
}
else
{
String location = RequestCycle.get()
.getRequest()
.getRelativePathPrefixToContextRoot() +
this.redirectUrl.substring(1);
// START OF PATCH
if (location.startsWith(./)) {
location = location.substring(2);
}
// END OF PATCH
response.redirect(location);
}
}
else if (redirectUrl.startsWith(http://;) ||
redirectUrl.startsWith(https://;))
{
response.redirect(redirectUrl);
}
else
{
response.redirect(RequestCycle.get()
.getRequest()
.getRelativePathPrefixToWicketHandler() +
redirectUrl);
}
}
---8--
was (Author: erikvanoosten):
I got bitten by this as well (with 1.4-m3).
The failing combination is: Tomcat and IE (6 or 7).
Firefox correctly interprets the ./ as so its okay to use Firefox + Tomcat.
Jetty converts ./ to , so its okay to use any borwser on Jetty.
My workaround was to patch these two Wicket core files (I can confirm it works):
BookmarkablePageRequestTarget:
---8--
public void respond(RequestCycle requestCycle)
{
if (pageClassRef != null pageClassRef.get() != null)
{
if (requestCycle.isRedirect())
{
IRequestCycleProcessor processor =
requestCycle.getProcessor();
String redirectUrl =
processor.getRequestCodingStrategy()
.encode(requestCycle, this)
.toString();
// START OF PATCH
if (redirectUrl.startsWith(./)) {
redirectUrl = redirectUrl.substring(2);
}
// END OF PATCH
requestCycle.getResponse().redirect(redirectUrl);
}
else
{
// Let the page render itself
getPage(requestCycle).renderPage();
}
}
}
---8--
RedirectRequestTarget:
---8--
public void
[jira] Commented: (WICKET-1449) './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
[
https://issues.apache.org/jira/browse/WICKET-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628321#action_12628321
]
Erik van Oosten commented on WICKET-1449:
-
Duplicate of WICKET-847.
I would rate this issue as a blocker as well.
'./' appended to URL causes HTTP 404 in Internet Explorer (using root context)
--
Key: WICKET-1449
URL: https://issues.apache.org/jira/browse/WICKET-1449
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.2
Environment: Wicket 1.3.2
JBoss 4.0/Jetty 6.1.7
JDK 1.6.0_03
Reporter: Will Hoover
Assignee: Alastair Maw
Fix For: 1.3.5
Original Estimate: 72h
Remaining Estimate: 72h
SYNOPSIS:
1) Web application is using the root context (/)
1) form.add(new Button(mybutton));
2) Button is clicked on any WebPage that is NOT MOUNTED
ISSUE:
WebRequestCodingStrategy.encode appends './' to the URL. The page is
redirected to http://www.mysite.com/./; It works fine in Firefox and Opera,
but in IE an HTTP 404 ('.' page is not found) is rendered.
Mounting the home page to something like '/home' solved the problem ('./' is
not appended, but this causes a redirect every time a use hits the page).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1349) Wicket Ajax response generates a ^ character in the javascript code
[
https://issues.apache.org/jira/browse/WICKET-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625300#action_12625300
]
Erik van Oosten commented on WICKET-1349:
-
We are using AjaxRequestTarget while at the client side we use jquery only and
therefore also have problems with the '^' in the raw stream.
By replacing the AjaxRequestTarget#encode method with the following, you get
proper XML escaping.
/**
* Encodes a string so it is safe to use inside CDATA blocks
*
* @param str
* @return encoded string
*/
protected String encode(String str)
{
if (str == null)
{
return null;
}
return Strings.replaceAll(str, ], ]]]![CDATA[).toString();
}
Wicket Ajax response generates a ^ character in the javascript code
-
Key: WICKET-1349
URL: https://issues.apache.org/jira/browse/WICKET-1349
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.1
Environment: IE6 and IE7
Reporter: Wen Tong Allan
Assignee: Igor Vaynberg
I have a page that uses AjaxFallbackDefaultDataTable (using
SortableDataProvider ). The markup contains user-define javascript that I
added. When I try to do some action (delete row) with the table, the page
doesn't refresh in IE6 and IE7. I checked the Wicket Ajax Debugger and it
displays:
ERROR: Error while parsing response: Object required
INFO: Invoking post-call handler(s)...
INFO: invoking failure handler(s)...
I also noticed that the user-define javascript that was returned by the ajax
debugger was appended by ^. (See javascript below):
// enable disable button.
function setButtonState() {
var formObj =
eval(document.getElementsByName(contactListForm)[0]^);
var state = anyChecked(formObj);
document.getElementsByName(deleteContactsButton)[0]^.disabled = !state;
document.getElementsByName(newContactGroupButton)[0]^.disabled = !state;
document.getElementsByName(newEventButton)[0]^.disabled
= !state;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12595347#action_12595347 ] Erik van Oosten commented on WICKET-1355: - Richard, that change was the whole point of the fix. Apparently there is still a problem with the z-index, but reverting this line will not fix the problem of this issue. Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Assignee: Janne Hietamäki Fix For: 1.3.4 Attachments: wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1534) Allow multiple URL coding strategies on the same mount path
[ https://issues.apache.org/jira/browse/WICKET-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589834#action_12589834 ] Erik van Oosten commented on WICKET-1534: - After a small investigation I found that a CompoundRequestTargetUrlCodingStrategy is indeed possible. However, it would not really work well unless WebRequestCodingStrategy is changed such that the IRequestTargetUrlCodingStrategy#matches methods are executed outside a synchronized block. In my application I have to access the database in the matches methods. (Although the data is heavily cached, I can not afford to have all requests to stand still while the database is accessed for one page.) I'll try to make new patches, but if someone else is quicker I would welcome that :) Allow multiple URL coding strategies on the same mount path --- Key: WICKET-1534 URL: https://issues.apache.org/jira/browse/WICKET-1534 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.3.3 Reporter: Erik van Oosten Fix For: 1.4-M1 Attachments: VersatileWebRequestCodingStrategy.java It is currently not possible to mount multiple URL coding strategies on the same mount path. However, in combination with method #matches(String urlPath) this would be quite easy to accomplish in a backward compatible way. Please find attached a class that can be used instead of WebRequestCodingStrategy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1534) Allow multiple URL coding strategies on the same mount path
[ https://issues.apache.org/jira/browse/WICKET-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-1534: Attachment: VersatileWebRequestCodingStrategy.java Allow multiple URL coding strategies on the same mount path --- Key: WICKET-1534 URL: https://issues.apache.org/jira/browse/WICKET-1534 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.3.3 Reporter: Erik van Oosten Fix For: 1.4-M1 Attachments: VersatileWebRequestCodingStrategy.java It is currently not possible to mount multiple URL coding strategies on the same mount path. However, in combination with method #matches(String urlPath) this would be quite easy to accomplish in a backward compatible way. Please find attached a class that can be used instead of WebRequestCodingStrategy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1534) Allow multiple URL coding strategies on the same mount path
[ https://issues.apache.org/jira/browse/WICKET-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589048#action_12589048 ] Erik van Oosten commented on WICKET-1534: - Nothing changes there. It is already possible that multiple URL encoders are mounted for the same page type. Allow multiple URL coding strategies on the same mount path --- Key: WICKET-1534 URL: https://issues.apache.org/jira/browse/WICKET-1534 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.3.3 Reporter: Erik van Oosten Fix For: 1.4-M1 Attachments: VersatileWebRequestCodingStrategy.java It is currently not possible to mount multiple URL coding strategies on the same mount path. However, in combination with method #matches(String urlPath) this would be quite easy to accomplish in a backward compatible way. Please find attached a class that can be used instead of WebRequestCodingStrategy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1484) class cast exception (String) in MixedParamUrlCodingStrategy with additional params with patch
[
https://issues.apache.org/jira/browse/WICKET-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589084#action_12589084
]
Erik van Oosten commented on WICKET-1484:
-
An alternative is to replace the getParameterMap() method in ServletWebRequest
like this:
public Map getParameterMap()
{
// Lazy-init parameter map. Only make one copy. It's more
efficient, and
// we can add stuff to it (which the BookmarkablePage stuff
does).
if (parameterMap == null)
{
parameterMap = new
HashMap(httpServletRequest.getParameterMap());
// Replace single value parameter arrays with a single string.
for (Iterator i = parameterMap.keySet().iterator(); i.hasNext(); )
{
Object key = i.next();
Object value = parameterMap.get(key);
if ((value instanceof String[]) ((String[]) value).length ==
1)
{
parameterMap.put(key, ((String[]) value)[0]);
}
}
}
// return a mutable copy
return parameterMap;
}
class cast exception (String) in MixedParamUrlCodingStrategy with additional
params with patch
--
Key: WICKET-1484
URL: https://issues.apache.org/jira/browse/WICKET-1484
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.2
Reporter: Michael Grinner
Attachments: 1484_patch.txt
MixedParamUrlCodingStrategy has a bug in
MixedParamUrlCodingStrategy
appendParameters
if (!parameterNamesToAdd.isEmpty())
{
boolean first = true;
final Iterator iterator;
if (UnitTestSettings.getSortUrlParameters())
{
iterator = new
TreeSet(parameterNamesToAdd).iterator();
}
else
{
iterator = parameterNamesToAdd.iterator();
}
while (iterator.hasNext())
{
url.append(first ? '?' : '');
String parameterName = (String)iterator.next();
@@@ String value = (String)parameters.get(parameterName);
url.append(urlEncode(parameterName)).append(=).append(urlEncode(value));
first = false;
}
}
where value should be a String[] not a String.
like in AbstractRequestTargetUrlCodingStrategy
appendParameters
String[] values = (String[])value;
for (int i = 0; i values.length; i++)
{
appendValue(url, entry.getKey().toString(), values[i]);
}
it works ok after patching MixedParamUrlCodingStrategy to
if (!parameterNamesToAdd.isEmpty()) {
boolean first = true;
final Iterator iterator;
if (UnitTestSettings.getSortUrlParameters()) {
iterator = new TreeSet(parameterNamesToAdd).iterator();
} else {
iterator = parameterNamesToAdd.iterator();
}
while (iterator.hasNext()) {
url.append(first ? '?' : '');
String parameterName = (String) iterator.next();
Object value = parameters.get(parameterName);
if (value != null) {
if (value instanceof String[]) {
String[] values = (String[]) value;
for (String element : values) {
url.append(this.urlEncode(parameterName)).append(=).append(this.urlEncode(element));
}
} else {
url.append(this.urlEncode(parameterName)).append(=).append(this.urlEncode(value.toString()));
}
}
first = false;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1329) AutoCompleteTextField's suggestion list *disappeared* when it is used inside a ModalWindow
[ https://issues.apache.org/jira/browse/WICKET-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586447#action_12586447 ] Erik van Oosten commented on WICKET-1329: - When the fix in [WICKET-1355] is applied, the changes for this bug should probably be undone. AutoCompleteTextField's suggestion list *disappeared* when it is used inside a ModalWindow -- Key: WICKET-1329 URL: https://issues.apache.org/jira/browse/WICKET-1329 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-final Reporter: Andy Chu Assignee: Gerolf Seitz Fix For: 1.3.3 When an AutoCompleteTextField is used in panel showed inside a ModalWindow, the dropdown list for suggestions will be disappeared. The reason is that the z-index of a normal ModalWindow is 2 while the z-index of the dropdown list is 1. And there is no way to set this parameter programatically. Therefore, the dropdown list is masked by the ModalWindow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586448#action_12586448 ] Erik van Oosten commented on WICKET-1355: - The changes for bug [WICKET-1329] should probably be undone when the fix attached to this issue is applied. Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Assignee: Janne Hietamäki Fix For: 1.3.4 Attachments: wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-1355: Attachment: (was: wicket-autocomplete.js) Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Fix For: 1.3.2 When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-1355: Attachment: wicket-autocomplete.js Removed the non-working attachment. The currently attached version works on all regular browsers. Note: we had to move the drop-down div to another location to prevent it from staying on the same location on the screen while the content is scrolled. It is now the sibling of the input element. This may cause problems in css. Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Fix For: 1.3.2 Attachments: wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1355) Autocomplete window has wrong position in scrolled context
Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Fix For: 1.3.2 Attachments: wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-1355: Attachment: wicket-autocomplete.js A fix for the problem. Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Fix For: 1.3.2 Attachments: wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569925#action_12569925 ] Erik van Oosten commented on WICKET-1355: - Attached code is not yet correct. Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Fix For: 1.3.2 Attachments: wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
