[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.
please help find an 'onBeforeRender' for behaviors attached to ComponentTag (wicket:for attribute)
Hi, I just added a patch to http://issues.apache.org/jira/browse/WICKET-1469 (support for wicket:for attribute). The implementation is based on that of the wicket:message attribute and works fine. However, I can't reliably convince the referred component to render its markup id. The problem is that the referred component might already have been rendered. I can't find a hook that is called /before/ the render phase starts for a behavior that is attached to a ComponentTag. ComponentTag#onBeforeRender is actually called /during/ rendering from Component#render (line 2426 in branch 1.4.x) and not before. This makes sense as the markup stream is only known until the rendering of a component is started. Anyway, I wouldn't know how to override this method as the instance is created elsewhere. So my questions are: Is there an appropriate hook? Can one be added easily? Is there another way to manipulate the component hierarchy from the markup stream? If no such hook is/will be available I propose to just drop this feature altogether. Regards, Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: wicket 1.5 build is failing because of 1.6 deps...
Neil, I am afraid you miss the most important argument: whether the core developer *want* to develop with Java 5. Its mostly their free time and love they put in Wicket, we should never forget that. (Of course they probably want to have users, etc. But in the end it is their decision.) Regards, Erik. Neil Curzon wrote: -1 to JDK 1.6 The possibility of excluding even 1% of potential users for the negligible benefit of using 1.6-specific features would be a bad decision. 1.5 is simply the right jdk to be developing frameworks in for now. Pro 1.6 crowd: Understand that the argument is not that anybody's organization *should* stay with JDK 1.5, but that some organizations *will* stay at 1.5 regardless of whether you think they should be up to date. If the jump from 1.5 to 1.6 was as big as the jump from 1.4 to 1.5, I would be firmly in the pro-1.6 camp, but the benefits just aren't worth the costs. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
[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.
Re: Request for input on new feature idea: wicket:for attribute
Nice! It must be a good idea then :) If you go beyond a simple sibling, the referred component can be anywhere on the page. I know of no reasonable simple way to refer such a component (except through code). Therefor I think it is reasonable to limit this feature to sibling components only. The route through code is always present. Regards, Erik. Jonas wrote: There's already a feature request in jira for this: https://issues.apache.org/jira/browse/WICKET-1469 I tried implementing it once, but I run into trouble with component hierarchy. Only allowing labels for sibling components would probably make the implementation a lot easier, but I'm not sure if this a too big limitation to only allow siblings. Consider the situation when the input field and the label are in different table cells, e.g. trtd wicket:id=...input wicket:id=... ...//tdtd wicket:id=...label wicket:id=... ...//td/tr but you need to append some attributes to the td tags (e.g. for coloring). If I understood correctly what you suggested, this usecase wouldn't be covered. cheers, Jonas -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: URL Rewriting in Wicket
Actually, you should override the WebRequestProcessor and return a custom RequestCodingStrategy from there. The custom RequestCodingStrategy would extend one of the default implementation and override urlCodingStrategyForPath and getRequestPath. Regards, Erik. Andreas Maza wrote: Hello, I would like to do a simple URL rewriting in my application: All requests containing a given path (e.g., a /x/...) should be filtered and redirected accordingly. In other words, for a request to http://www.example.com/x/something I want to do a database lookup based on the value of something and then redirect the user to the appropriate wicket page. What is the recommended way to do this in wicket? Make a hook into the WebApplication.newRequestCycle() method? thanks for your help, andr -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Request for input on new feature idea: wicket:for attribute
Hi, In the many Wicket applications I have seen, the most frequent error is to not correctly set the 'for' attribute of an HTML 'label' element. Currently it is necessary to do this from code. Although a quickly written component will make this fairly easy, the task is occurring that often that imho better support by wicket is warranted. I therefore propose a new wicket:for attribute that looks as follows: label *wicket:for=name*Name/label input wicket:id=name type=text/ The rendered markup could for example be: label for=name78Name/label input id=name78 name=name78 type=text value=.../ Some more thoughts on the design of the wicket:for attribute: - The value of the attribute refers to a component by component id. The referred component must be a sibling of the same container that provides the markup with the label element. Referring to a component outside this container is tricky as then component ids are no longer unique. - The wicket:for attribute will render the 'for' attribute with the markup id of the referenced component as value. - The method setOuputMarkupId(true) will be called on the referenced component. More ideas? If I would implement such a wicket:for attribute, would it be accepted in Wicket core? Regards, Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
[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.
Re: Session stealing with wicket-auth-roles
Thats basically the same code as on http://randomcoder.com/articles/jsessionid-considered-harmful. OWASP also has a good deal to say about sessions: http://www.owasp.org/index.php/Session_Management Regards, Erik. James Carman wrote: The Seam folks have a fix for removing JSESSIONID from the URLs, too: http://seamframework.org/Documentation/RemovingJSESSIONIDFromYourURLsAndFixingScache -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Session Invalidation Options
Thanks Michael. Erik. Michael Mosmann wrote: Hope this code will make something clear. mm:) -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: Session Invalidation Options
Michael, What kind of container are you referring to? And which session, the servlet session or the Wicket session? Regards, Erik. Michael Mosmann wrote: Hi, I've got a business requirement that session invalidation must not be a disruptive event (no expired session warning or anything similar). Is session invalidation an requirement? Put a container into your session and throw it away if you want to invalidate the user session. mm:) -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: [1.4.3] RequestUtils.toAbsolutePath() skips the last value
Hello Smallufo, Please open an issue on the Wicket jira so that the development team can track this bug. Regards, Erik. smallufo wrote: The code is following : WebApplication : mountBookmarkablePage(/TestPage , TestPage.class); TestPage.html : url = span wicket:id=url/span TestPage.java : final String url = RequestUtils.toAbsolutePath(); add(new Label(url , Model.of(url))); If I open http://foobar:8080/quickstart/app/TestPage it shows http://foobar:8080/quickstart/app/TestPage , correct if I open http://foobar:8080/quickstart/app/TestPage/a/b/ it shows : http://foobar:8080/quickstart/app/TestPage/a/b/ , correct BUT , if I open http://foobar:8080/quickstart/app/TestPage/a/b it shows : http://foobar:8080/quickstart/app/TestPage/a , WRONG -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
[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.
WICKET-1355 autocomplete positioning
Hi, After 13 months I finally got around creating a proper patch for the wrong autocomplete dropdown positioning, (https://issues.apache.org/jira/browse/WICKET-1355). I added 2 patch files to the issue, one for 1.3.x, and one for 1.4.x/trunk. The patches are based on a version I created to patch wicket 1.3.6. The changes are very straight forward but I did not actually test the patches on 1.3.x, 1.4.x nor trunk. Please let me know if it works for you. Regards, Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: remove MarkupContainer.isTransparentResolver
Can we not use just this TransparentMarkupContainer and add the atrtibutemodifiers to that component? Erik. Juergen Donnerstag wrote: Yes, it is trivial. Just copy the code from the TransparentMarkupContainer (still on my disk). As another option: In 1.5 we removed the final keyword from MarkupContainer.add(Component...) - see Border.java for the use case - so that in 1.5 you may also subclass add() and thus keep the markup and component hierarchies in sync. -Juergen On Mon, Nov 9, 2009 at 5:16 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: you guys can still do that by allowing your webmarkupcontainer to implement icomponentresolver instead of simply overriding istransparentresolver(true). the impl itself should be trivia, just check for the component in the page body. -igor -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: remove MarkupContainer.isTransparentResolver
Ah yes, I do that as well. Regards, Erik. Olivier Croisier wrote: I use the same technique (WebMarkupContainer + isTransparentResolver=true) on the body element to add an id attribute to it, with a unique value for each page extending the base template. This is useful to build unique CSS selectors for each page. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: remove MarkupContainer.isTransparentResolver
This will break almost every project I have (in a trivial way), but if it will simplify the Wicket core you have my: +1 (non binding) Regards, Erik. Juergen Donnerstag wrote: Hi, MarkupContainer.isTransparentResolver() regularly is the root cause for some problems where users don't fully understand the implications. It's main purpose is for auto-components which shall be hidden from the user. Unfortunately it is at a very prominent position and may be too easy to use. IComponentResolver can do the same and is a the more generic approach. In order to serve isTransparentResolver() there is special code spread around core. I'd like to remove isTransparentResolver() from 1.5. I made TransparentWebMarkupContainer a top level class and tested it. It's working fine. What do you think? -Juergen -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: Howto test redirect to non-wicket base page
Per,
You can also throw a RestartResponseException or a subclass thereof.
That is the recommended way within a constructor anyway. For you it
would be RedirectToUrlException (or something like that).
Regards,
Erik.
Per Newgro wrote:
Hi *,
i would like to test behavior of my page. In constructor there is a redirect if
page parameter not set. But the redirect target is a url and not a wicket page
instance. What is the best attribute to add my assertion to?
MyPage(PageParams p) {
if (p.get(xyz) == null) {
redirectTo(http://www.myurl.ch;);
}
add(new Label(Rendered);
}
void redirectTo(String url) {
getRequestCycle().setRedirect(true);
getRequestCycle().setRequestTarget(new RedirectRequestTarget(url));
}
lastRenderedPage is null so i can't add my assertion to this.
Cheers
Per
--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: London Wicket Event, Saturday November 21st
Igor Vaynberg wrote: until i see some video proof i will continue to operate under my assumption - there are no presentations, this is just an excuse to get out of the house and go to a pub :) -igor For sure, they /will/ visit a pub... -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [wicket 1.5] url handling refactor preview
On Sun, 4 Oct 2009 13:21:13 -0700, Igor Vaynberg igor.vaynb...@gmail.com wrote: but then all you are doing is repeating the information that is already in the method signature in the method name. why? -igor Very simple: communication. In my previous e-mail I constantly had to write map(RequestHandler) or map(Request) in order to say which method I was talking about. Also, in the reply of Matje I had to read very carefully to see which map method he was writing about. Regards, Erik.
Re: [wicket 1.5] url handling refactor preview
Matej Knopp wrote: On Sun, Oct 4, 2009 at 3:03 PM, Erik van Oosten e.vanoos...@grons.nl wrote: * I am a bit confused about the RequestHandler interface. It contains nothing to get the request's parameters. How is method RequestMapper#map(RequestHandler) supposed to work then? I guess it will always need to know about the types of RequestHandlers it supports. This introduces a tight coupling I did not expect. (I am not saying it is wrong, it just confused me.) RequestHandler should not care about request parameters at all. That's what RequestMapper does. It takes request and produces RequestHandler. It must of course know which handlers to produce and which it can accept (to generate URLs). On the other hand RequestHandler doesn't know about RequestMapper nor should it. It's not tight coupling, just a chain of responsibility. RequestMapper knows how to parse urls and create request handlers, it also knows how to produce URLs for those request handlers. The responsibility of RequestHandler is to produce response (which can sometimes include other activities, such as invoking listener interface on components). I think I get your point: each RequestMapper is responsible for both Url - ReqeustHandler conversions and therefore should always know what its doing. Still, there is a tight coupling (I now understand, a good uni-directional one) between each RequestMapper instance to the RequestHandlers it supports. * I guess BufferedResponseMapper#getCompatibilityScore should return Integer.MIN_VALUE (instead of 0) when it can not process the request. Or is 0 a kind of magic value? Well, if being the smallest positive number counts as magical then yes. If java had unsigned numbers the result type would be unsigned int. Look at RequestMapper#getCompatibilityScore javadoc. There is a suggestion how the algorithm should work (matching number of segments). Right, I saw that. I guess some kind of documentation is needed that will vaguely describe what numbers are expected. I was also thinking about the name. The score is my thinking more about precedence then about compatibility (though after some more thinking I understand the term). What do you think about PrecedenceScore? * When I look at ThreadsafeCompoundRequestMapper I am a (little) bit worried about performance. The main worry is that methods are called multiple times for the same request. For example method getCompatibilityScore of the nested RequestMappers is called in both map(Request) as in getCompatibilityScore. A request mapper can not simultaneously calculate a map and a compatibility score precluding some optimizations. Premature optimizations most probably. Unless you have thousands of mount points. Also, implementation wise compatibility score can be completely independent to request decoding. Nevertheless should this become a bottleneck (which i think is highly unlikely) we can cache the compatibility score during request in RequestCycle metadata. Yes, very true. Regards, Erik. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
[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
[Ubuntu-x-swat] [Bug 112310] Re: Setting Wacom pen button to double click doesn't work
Confirming that value 196609 does not work on Ubunu 9.04: e...@oosttop:~$ sudo tail -f /var/log/Xorg.0.log (**) Wacom Bamboo: max y = 9225 (**) Wacom Bamboo: max z = 511 (**) Option Button2 3 (**) Wacom Bamboo: button2 assigned to 3 (**) Option Button3 196609 (**) Wacom Bamboo: button3 assigned to 196609 (**) Option BaudRate 9600 (**) Wacom Bamboo: serial speed 9600 (II) XINPUT: Adding extended input device Wacom Bamboo (type: Wacom Stylus) (==) Wacom device Wacom Bamboo top X=0 top Y=0 bottom X=14760 bottom Y=9225 resol X=2540 resol Y=2540 Still no double click behavior though. -- Setting Wacom pen button to double click doesn't work https://bugs.launchpad.net/bugs/112310 You received this bug notification because you are a member of Ubuntu-X, which is subscribed to xorg in ubuntu. ___ Mailing list: https://launchpad.net/~ubuntu-x-swat Post to : ubuntu-x-swat@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-x-swat More help : https://help.launchpad.net/ListHelp
[Bug 112310] Re: Setting Wacom pen button to double click doesn't work
Confirming that value 196609 does not work on Ubunu 9.04: e...@oosttop:~$ sudo tail -f /var/log/Xorg.0.log (**) Wacom Bamboo: max y = 9225 (**) Wacom Bamboo: max z = 511 (**) Option Button2 3 (**) Wacom Bamboo: button2 assigned to 3 (**) Option Button3 196609 (**) Wacom Bamboo: button3 assigned to 196609 (**) Option BaudRate 9600 (**) Wacom Bamboo: serial speed 9600 (II) XINPUT: Adding extended input device Wacom Bamboo (type: Wacom Stylus) (==) Wacom device Wacom Bamboo top X=0 top Y=0 bottom X=14760 bottom Y=9225 resol X=2540 resol Y=2540 Still no double click behavior though. -- Setting Wacom pen button to double click doesn't work https://bugs.launchpad.net/bugs/112310 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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.
Re: Choose one
Call setRequired(false) on the dropdownchoice. Regards, Erik. Gatos wrote: After I choose something in DropDownChoice then 'Choose one' item is removed from the list. If I will try to use setNullValid(true) then 'Choose one' string is replaced with '' (emptry string). How is it possible to display 'Choose one' if another item has been selected? -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Absolute urls in forms
I added a patch in Jira. Regards, Erik. Erik van Oosten wrote: Anyways, you can make all URLs absolute by following the hints in https://issues.apache.org/jira/browse/WICKET-1974. You'll need to patch Wicket as the issue is not yet solved. (I really should make the patch, its soo easy, just have to find time.) -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ -- View this message in context: http://www.nabble.com/Absolute-urls-in-forms-tp25075543p25132710.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
[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.
Re: Absolute urls in forms
I've always wondered about that Anyways, you can make all URLs absolute by following the hints in https://issues.apache.org/jira/browse/WICKET-1974. You'll need to patch Wicket as the issue is not yet solved. (I really should make the patch, its soo easy, just have to find time.) Regards, Erik. Igor Vaynberg wrote: thats funny, we worked really had to make all urls relative because it would make it a lot easier to work with proxies... :) -igor -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Removing an element from ListView with AjaxFallbackButton
Perhaps you can use the list editor: http://wicketinaction.com/2008/10/building-a-listeditor-form-component/ Regards, Erik. Major Péter wrote: Any help would be appreciated. Thanks Regards, Peter -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to add Random number to URL ?
You request puzzles me. By default Wicket adds headers to every page that will make any decent browser written since 1996 not cache the page. What is your intention? Regards, Erik. FaRHaN wrote: How can i use this for every request ? As i want to generate a unique URL for every page (not for images), any examples ??? -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StringResourceModel ignores Converters?
Hi Matt, Converters are only used during form submission. So to answer your question: this seems like a feature. Regards, Erik. Matthias Keller wrote: Hi I need to use a StringResourceModel to compile a string with multiple parameter substitutions. I have a lot of converters active which should take care of all these values and which do work when using for example a PropertyModel elsewhere. Unfortunately it seems the converters are completely ignored for StringResourceModels when doing the parameter substitution? I always get the data in its raw (.toString) form instead of the converted?! Is this a bug or a feature? Thanks Matt -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicketstuff releases?
Regarding step 2: only change the dependency to Wicket in the wicketstuff-core pom.xml, not the versions of wicketstuff poms themselfs (as I just did). Regards, Erik. Jeremy Thomerson wrote: To those who have written me volunteering to help: thank you. I will try to do the release this weekend. Here's what you can do to help before then. 1 - check out wicketstuff-core trunk 2 - change the wicket dependencies from snapshot to 1.4.0 (note: only do this locally - don't commit that change - since trunk should run on trunk) 3 - build it to make sure it all works 4 - test the release process by doing following: mvn release:prepare -DdryRun=true If all of that is working fine (no build errors, etc), then let the list know. That will make it much easier to do the release. And I'll try to document the process so that someone else can perform the next one easier. -- Jeremy Thomerson http://www.wickettraining.com -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicketstuff core 1.4.0 release preparations
Hi Jeremy, I am afraid I do not understand what to do. I set out to test the yui-parent module: I can confirm that /yui-parent/ builds fine (with +mvn install+). Yeah! However, +mvn release:prepare -DdryRun=true+ executed in the yui-parent sub-directory just downloads a yui snapshot instead of compiling it localy. Running it one directory up fails because prepare:release does not accept diffs with the SCM and I changed the wicketstuff-code pom (I commented out all modules except for yui-parent). What else can I do? Or must one do the whole thing at once? BTW, should wicketstuff-core not change from 1.4-SNAPSHOT to 1.4.0-SNAPSHOT? Regards, Erik. Jeremy Thomerson wrote: To those who have written me volunteering to help: thank you. I will try to do the release this weekend. Here's what you can do to help before then. 1 - check out wicketstuff-core trunk 2 - change the wicket dependencies from snapshot to 1.4.0 (note: only do this locally - don't commit that change - since trunk should run on trunk) 3 - build it to make sure it all works 4 - test the release process by doing following: mvn release:prepare -DdryRun=true If all of that is working fine (no build errors, etc), then let the list know. That will make it much easier to do the release. And I'll try to document the process so that someone else can perform the next one easier. -- Jeremy Thomerson http://www.wickettraining.com -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicketstuff core 1.4.0 release preparations
Igor, release:prepare automatically also does clean and package. There is actually one more thing I could have tried: execute the release:prepare goals in de yui sub-sub modules. Regards, Erik. Igor Vaynberg wrote: mvn clean package release:prepare -DdryRun=true -igor On Thu, Aug 13, 2009 at 8:33 AM, Erik van Oostene.vanoos...@grons.nl wrote: Hi Jeremy, I am afraid I do not understand what to do. I set out to test the yui-parent module: I can confirm that /yui-parent/ builds fine (with +mvn install+). Yeah! However, +mvn release:prepare -DdryRun=true+ executed in the yui-parent sub-directory just downloads a yui snapshot instead of compiling it localy. Running it one directory up fails because prepare:release does not accept diffs with the SCM and I changed the wicketstuff-code pom (I commented out all modules except for yui-parent). What else can I do? Or must one do the whole thing at once? BTW, should wicketstuff-core not change from 1.4-SNAPSHOT to 1.4.0-SNAPSHOT? Regards, Erik. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicketstuff core 1.4.0 release preparations
Yes, that did it. Running the dryRun in wicket-stuff/wicketstuff-core/yui-parent/yui succeeds. I repeated this for yui-examples. yui-parent, yui and yui-examples are ready to go! Regards, Erik. Erik van Oosten wrote: There is actually one more thing I could have tried: execute the release:prepare goals in de yui sub-sub modules. Igor Vaynberg wrote: mvn clean package release:prepare -DdryRun=true -igor On Thu, Aug 13, 2009 at 8:33 AM, Erik van Oostene.vanoos...@grons.nl wrote: Hi Jeremy, I am afraid I do not understand what to do. I set out to test the yui-parent module: I can confirm that /yui-parent/ builds fine (with +mvn install+). Yeah! However, +mvn release:prepare -DdryRun=true+ executed in the yui-parent sub-directory just downloads a yui snapshot instead of compiling it localy. Running it one directory up fails because prepare:release does not accept diffs with the SCM and I changed the wicketstuff-code pom (I commented out all modules except for yui-parent). What else can I do? Or must one do the whole thing at once? BTW, should wicketstuff-core not change from 1.4-SNAPSHOT to 1.4.0-SNAPSHOT? Regards, Erik. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicketstuff core 1.4.0 release preparations
Hi, Unfortunately tinymce does /not/ compile. It fails with a missing dependency to jazzyplugin:jazzyplugin:jar:0.2.1. Regards, Erik. Jeremy Thomerson wrote: To those who have written me volunteering to help: thank you. I will try to do the release this weekend. Here's what you can do to help before then. 1 - check out wicketstuff-core trunk 2 - change the wicket dependencies from snapshot to 1.4.0 (note: only do this locally - don't commit that change - since trunk should run on trunk) 3 - build it to make sure it all works 4 - test the release process by doing following: mvn release:prepare -DdryRun=true If all of that is working fine (no build errors, etc), then let the list know. That will make it much easier to do the release. And I'll try to document the process so that someone else can perform the next one easier. -- Jeremy Thomerson http://www.wickettraining.com -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicketstuff core 1.4.0 release preparations
Maarten, you just beated me to it. Is the jazzyplugin still needed after your changes? Regards, Erik. Erik van Oosten wrote: Hi, Unfortunately tinymce does /not/ compile. It fails with a missing dependency to jazzyplugin:jazzyplugin:jar:0.2.1. Regards, Erik. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicketstuff releases?
Hello, Now that Wicket 1.4.0 is out, I wonder which wicketstuff core version is compatible. There is no 1.4.0 version of wicketstuff core (yet?). Should I use 1.4-rc8-SNAPSHOT? I guess http://sourceforge.net/projects/wicket-stuff/files/ is no longer in use. Regards, Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicketstuff releases?
Maarten, AFAIK wicketstuff-core trunk is compatible with wicket 1.4.0 Yes, I know. But my client is not really happy about using trunk/snapshots in a production system. And frankly, neither am I. I love snapshot releases, but if I can prevent the extra steps needed to use them in production I would. Side note: I don't see the version of wicket-stuff has to match exactly with version of wicket ? Suppose someone releases wicketstuff-core-1.4.0 today, and tomorrow some bugs are fixed in wicketstuff-core, then we can't release these bug-fixes until wicket 1.4.1 is out ? I agree. Its just that right now there is no release at all. As soon as there are more releases of the wicketstuff-core projects and/or wicket, it makes sense to start a compatibility matrix. BTW, I don't really care if wicketstuff-core is completely 100% stable, it will never be. Promoting every first snapshot of the month to a release is good enough for me. Regards, Erik. On Wed, 12 Aug 2009 10:24:07 +0200, Maarten Bosteels mbosteels@gmail.com wrote: Hello, On Wed, Aug 12, 2009 at 10:16 AM, Erik van Oosten e.vanoos...@grons.nlwrote: Hello, Now that Wicket 1.4.0 is out, I wonder which wicketstuff core version is compatible. There is no 1.4.0 version of wicketstuff core (yet?). Should I use 1.4-rc8-SNAPSHOT? AFAIK wicketstuff-core trunk is compatible with wicket 1.4.0 Side note: I don't see the version of wicket-stuff has to match exactly with version of wicket ? Suppose someone releases wicketstuff-core-1.4.0 today, and tomorrow some bugs are fixed in wicketstuff-core, then we can't release these bug-fixes until wicket 1.4.1 is out ? IMO, wicket is just a dependency of wicketstuff-code (as defoined in the pom) and both projects should use their own unrelated version numbers. wdyt ? Maarten I guess http://sourceforge.net/projects/wicket-stuff/files/ is no longer in use. Regards, Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Changing a Form's Model
I am glad you got that right :) If the model has changed, call modelChanged() on the form (and/or the form components, not sure). There is no need to again set the model. Regards, Erik. Troy Cauble wrote: in a form that gets reused (repetitively in the same page). Don't you ever re-use a component! Sharing models/behaviors is fine, sharing components is not. Thanks, Erik, but I'm pretty sure we're talking about different things. I'm just using components on a page and changing the data. (Reusing the form *over time*.) I have Page DropDownChoice Form Fields When an entity is selected with the DDC, the form is made visible and filled with the model/data of the entity. When a save button is hit the form is hidden and the DDC reset (Choose one...). You're not saying the Form should be discarded and rebuilt, are you? Thanks, -troy -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Output to input stream for streaming?
With 'output' I meant the servlet request output. But perhaps I misunderstood the question. I guess the problem is that you close 'inputStream' as soon as the request is finished. The thread that tries to write to it is still active at that moment. Regards, Erik. Martin Makundi wrote: Maybe the thread is wrongly written, yes but a servlet CAN read a FILE. A file is always another PROCESS (which supplies the file contents, yes, it's the disk driver etc.). So a similar configuration should be possible between a write operation and an input stream. Anybody have experience with pipedstreams? There is an article about it here, but I may have misunderstood the details: http://ostermiller.org/convert_java_outputstream_inputstream.html ** Martin 2009/8/10 Erik van Oosten e.vanoos...@grons.nl: That won't work. Servlets are synchronous; they don't expect anyone writing the output once the servlet finished. Regards, Erik -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: DataTable with more than one tr per item
Kariem, There is a hint at http://cwiki.apache.org/WICKET/wickets-xhtml-tags.html#Wicket%27sXHTMLtags-Elementwicket:container Regards, Erik. Igor Vaynberg wrote: no, a datatable doesnt support that. but it is easy enough with your own repeater. -igor -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Help us release 1.4 sooner by helping out with the migration guide
If I remember correctly: the first link should be use. The second can be edited and will be copied to the first after each change. If the pages are not equal, something went wrong with the copy process. Re. LinkTree: every change should be on this page. Please add it. Regards, Erik. Major Péter wrote: Hmm... On the Wiki page did you forgot the LinkTree modification, or isn't that so relevant, to put it on wiki? Also it is strange that there are two wiki pages for migrating guide: http://cwiki.apache.org/WICKET/migrate-14.html and http://cwiki.apache.org/confluence/display/WICKET/Migrating+to+Wicket+1.4 The second one is a little more detailed, than the first one, but Martijn has linked the first one just before. Don't you need to synchronize this two page? Regards, Peter 2009-07-14 03:47 keltezéssel, Igor Vaynberg írta: thanks major, i added a couple of notes to the wiki. i totally forgot about 2350, i will get it into 1.4.0 for sure. -igor 2009/7/11 Major Pétermajorpe...@sch.bme.hu: Hi, I have recently upgraded my project and I did find these changes: - the first parameter of org.apache.wicket.markup.html.tree.LinkTree#onNodeLinkClicked has been changed from TreeNode to Object, so if you had override this method, you need to change the parametertype. - localization messages for validations works only in form.component.validatorType=message format, the component.validatorType=message format isn't working anymore (but this could be change for final release - for further infos see: https://issues.apache.org/jira/browse/WICKET-2350 ) Besides this, I found in WebApplication#getConfigurationType a FIXME comment, so in theory the init-param's name for filter/servlet (or context-param) should be changed from configuration to wicket.configuration in final 1.4 release. (See: https://issues.apache.org/jira/browse/WICKET-1317 ) //Also many old component has been genericized, a list of these components would be helpful, (for example TextField, RequiredTF, and so on, if you follow these changes in your code, it would be easier to read next time) p.s: I would wrote this on wiki, but I know how bad my english is. :) Best Regards, Peter Major 2009-07-10 21:22 keltezéssel, Igor Vaynberg írta: We would like to release Wicket 1.4 very soon, but in order to do so we would like to provide our users with a good migration guide. We have started one here: http://cwiki.apache.org/confluence/display/WICKET/Migrate-1.4 but it probably lacks the smaller tweaks necessary to migrate. If you have recently migrated a project, or remember any changes you had to perform, or have any helpful tips or hints please add them to the migration guide. Do not worry about formatting, for now we are looking for content. If you do not want to bother putting them on the wiki simply add them to this thread. Thanks! -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket rewriting name attributes in form
Hi Bas, Wicket needs to write a generated name attribute so that it knows exactly which value comes back from the client. But since you're not posting to the server but to some other script, why bother with using Wicket components? Just use the raw html, and if you must use Label and WebMarkupContainer to manipulate the html. Regards, Erik. Bas Vroling schreef: I have written an wicket page that collects some user input and calculates values. These values need to be sent to an external python script that does something with this data and renders a results page. This almost works fine but wicket messes up my form. In the HTML template I have specified my form like this: form method=post action=some_url input type=text class=field wicket:id=proteinId name=protein_id / input type=submit class=button value=Go! / /form but when wicket renders the page it creates this: form method=post action=some_url input type=text class=field wicket:id=proteinId name=mutantPredictionSubmitPanel:proteinId value=adrb2_human/ input type=submit class=button value=Go! / /form The difference is in the name of proteinId value being rewritten from protein_id to mutantPredictionSubmitPanel:proteinId, and this causes the python script at the other end to choke. Is there a way to disable the rewriting of the name attribute, or specify my own name? -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicketstuff checkout fails
Hi, I am trying to do a checkout of wicketstuff but I get redirected to the same URL: e...@oostblok:~/projects/wicketstuff$ svn co http://wicketstuff.org/maven/repository/org/wicketstuff/tinymce/ svn: Repository moved temporarily to 'http://wicketstuff.org/maven/repository/org/wicketstuff/tinymce/'; please relocate e...@oostblok:~/projects/wicketstuff$ Accessing the repo with FF is no problem. Am I doing something wrong? Regards, Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicketstuff checkout fails
Aacchh!! Me hit forehead with table Martin Funk wrote what are you trying to do? that url is no subversion repo, but a maven repo. maybe you were looking for this: http://sourceforge.net/projects/wicket-stuff/develop mf - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Caching a resource on the browser side
.
As the files are users specific (and determined with data from the
session), we went for some page delivering the content like this :
public AMChartDataProviderPage(final PageParameters parameters)
{
Object object = parameters.get(DATA_KEY);
if ((object == null) || !(object instanceof String) ||
.equals(object))
{
throw new IllegalStateException(Expected parameter +
DATA_KEY + not provided or empty);
}
String dataId = (String) object;
ByteArrayResource resourceStream;
try
{
resourceStream = new ByteArrayResource(text/csv,
IOHelper.getResourceAsByteArray(dataId + .csv));
}
catch (IOException e)
{
throw ExceptionHelper.wrap(e);
}
getRequestCycle().setRequestTarget(new
ResourceStreamRequestTarget(resourceStream.getResourceStream()));
}
However, I don't manage to get this resource to be cached on the user
browser side, despite the resource being cacheable. From what I've
seen, setHeaders() in WebResource is never called... Neither did I
manage to set them myself (on the page they're never called neither...
and the request cycle has no webresponse on which to define the
header).
Any clue ?
thanks in advance
zedros
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
http://www.autoladu.ee - kõik varuosad ühes kohas
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
http://www.autoladu.ee - kõik varuosad ühes kohas
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Stateless login form?
Ah, I get it. Yes, you are right too, just never got around rewriting the login to a stateless form. It has no priority though as our session never dies. Regards, Erik. Martin Makundi wrote: Login page is visible, but the form action=/?wicket:interface=:0:1 which is stateful. If my session dies I will definitely get an error. Try clicking this link with a new browser that does not have a session on the site: http://www.tipspot.com/?wicket:interface=:0:1 This is what you would get if your browser loaded the page from cache (or if you let it wait until the session invalidates). Does not look professional and it is totaly unnecessary, in my opinnion. It should be possible to handle forms on virgin (=no state bound yet) invocations too. ** Martin 2009/8/2 Erik van Oosten e.vanoos...@grons.nl: Martin, I am not sure what you mean. On the site you are referring, the login page is always visible under /login. Regards, Erik. Martin Makundi wrote: If I understood correctly, you might find this interesting: http://day-to-day-stuff.blogspot.com/2008/10/wicket-extreme-consistent-urls.html Does appear to make stateless-looking urls AFTER you CLICK/REDIRECT (looking at the example page referred on the site). Not BEFORE you CLICK... -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Adding javascript after tab clicked
That can not be right. The javascript added with AjaxRequestTarget#appendJavascript should be executed /after/ the DOM manipulations have finished. Maybe you called prependJavascript by accident? Or do you refer to something another thing when you write 'before the rendering finishes'? BTW, I assume you are using an overriden AjaxTabbedPanel#onAjaxUpdate. Regards, Erik. Cristi Manole wrote: Hello, Tks for the reply. Yes, I'm using that, the problem is it gets called before the rendering finishes. I need something that runs after it got rendered. Any ideas? Cristi On Mon, Aug 3, 2009 at 1:07 PM, Eyal Golan egola...@gmail.com wrote: I'm not sure, but are you looking for this: AjaxRequestTarget #appendJavascript(javascript) ? Eyal Golan egola...@gmail.com -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Stateless login form?
Martin, I am not sure what you mean. On the site you are referring, the login page is always visible under /login. Regards, Erik. Martin Makundi wrote: If I understood correctly, you might find this interesting: http://day-to-day-stuff.blogspot.com/2008/10/wicket-extreme-consistent-urls.html Does appear to make stateless-looking urls AFTER you CLICK/REDIRECT (looking at the example page referred on the site). Not BEFORE you CLICK... - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
[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.
Re: How to use Session.replaceSession() ??
Try this in a method of your WebSession subclass: ((WebRequest) RequestCycle.get().getRequest()).getHttpServletRequest().getSession().invalidate(); // Bind forces a connect of the current Wicket session to the new HTTP session. bind(); Regards, Erik. Matthias Keller wrote: Hi I'm writing our custom internal error handler which is supposed to terminate the current session and create a new one (in order to pass over the locale to the new session). I've stumbled upon the Session.replaceSession() method which, according to the javadoc, should just exactly do that. But when I call this method, nothing happens. The same session continues to be used and no new session is being created at all?! I've got it to work by using: Session newSession = getApplication().newSession(getRequest(), getResponse()); newSession.setLocale(getSession().getLocale()); getSession().invalidateNow(); Session.unset(); newSession.replaceSession(); But I think there must be something easier... ???! Thanks Matt -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Ajax indicator turning off
This seems like something that warrants a new Jira issue. Regards, Erik. John Patterson wrote: paolo di tommaso wrote: Yep, intercept the ajax call and inc/dec a counter -- paolo Although I could correct the indicator behaviour in all my own AJAX components, it would probably make more sense to incorporate it into wickets default AJAX behaviour. If people think it makes sense I can supply a patch. John -- View this message in context: http://www.nabble.com/Ajax-indicator-turning-off-tp24655744p24694924.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Questions about Wicket sessions
Igor Vaynberg wrote: 2. If I start IE or FF in another window, visitor activities on the same Wicket app are considered in the same or different session? always a different sessions, browsers do not share sessions. I think it depends on what David meant by 'another window'. I assumed it to be the 'open in new window' function. Then you still have the same browser, but another window. Regards. Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UnauthorizedActionException wrapped in an InvalidUrlException - how to deal with it ?
Olger Warnier schreef: Intresting, I assume that it is of value to have this construction, could you give me the link to the RFE ? https://issues.apache.org/jira/browse/WICKET-2200 -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UnauthorizedActionException wrapped in an InvalidUrlException - how to deal with it ?
Sorry Olger, that was a copy paste error. Please see Alex' e-mail. Regards, Erik. Erik van Oosten schreef: Olger Warnier schreef: Intresting, I assume that it is of value to have this construction, could you give me the link to the RFE ? https://issues.apache.org/jira/browse/WICKET-2200 -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Questions about Wicket sessions
David, Please note Sessions are not thread-safe in Wicket context means that the Session /object/ is not thread-safe. Note that requests that fall within a session (except for resources) are handled serially. Only when you use session clustering this guarantee can not be made. 1. It depends on the browser. All modern browsers will make it one session. 2. Same answer. 3. No. Wicket does this for you. Regarding your question on session storage: you'll be hard pressed to find a more performant solution to Wicket's http session disk store. Perhaps that memory solutions would work better. Regards, Erik. David Chang wrote: Reading Wicket in Action to learn Wicket, I understand that sessions are not thread-safe. I have the following questions about a Wicket app: 1. If I open another tab on the same browser (IE or FF), visitor activities on the same Wicket app are considered in the same session? 2. If I start IE or FF in another window, visitor activities on the same Wicket app are considered in the same or different session? 3. If dirty() is called within a method of custom session object, then it is the developer's responsibility to implement dirty() to synchronize with other clustered web servers, correct? Thanks! - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [OT] Continue to support Wicket 1.2 in WicketForge
Mostly Wicket 1.4 at my company, just 1 Wicket 1.3 project left. Regards, Erik. Nick Heudecker wrote: Hi, For those of you that don't know, I maintain WicketForge, the Wicket plugin for IDEA (http://plugins.intellij.net/plugin/?id=1545 or http://code.google.com/p/wicketforge). Currently, WicketForge supports Wicket 1.2 in addition to 1.3 and 1.4, but I'd like to remove support for 1.2 to clean a few things up. First, I want to see if people are still using 1.2 with WF. My question to you is: are you still using WicketForge with Wicket 1.2? Thanks for your time and feedback. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [vote] release wicket 1.4.0
Non binding. [X] Yes release 1.4.0 [ ] No, don't release it -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: Spring and Wicket - is it worth it?
Spring gives flexibility in your services layer (whatever you call it). Making things transactional, adding memoization, talking to remote interfaces, configuring Hibernate and JMX beans, all that kind of stuff is easy with Spring and often unbelievably hard without. As said, Spring has no value in a Wicket application with the exception of calling out to the service layer. This is where the @SpringBean comes in handy. Regards, Erik. On Wed, 22 Jul 2009 18:40:19 -0700, Dane Laverty danelave...@gmail.com wrote: Due to the fact that nearly every substantial sample Wicket app is Spring-based, I imagine that there's something awesome about using Spring. In fact, Wicket is what has finally gotten me to start learning Spring. I think I understand the basics of dependency injection -- configure your objects in xml files and then inject them into your classes -- but I'm still not clear on the advantage of it. I've read quite a ways into Spring in Action, and the author seems to assume that the reader will automatically see why xml-based dependency injection is great thing. I must just be missing something here. What I love about Wicket is being free from xml files. Can anyone give me a concise explanation of how the advantages of Spring are worth introducing a new layer into my applications? Dane -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Updating an inmethod grid, looking for hints
Hi Matej, I finally found the bug. When you are using a DefaultDataGrid it adds a PagingToolbar. PagingToolbar overrides isVisible. In isVisible the total row count is determined, this will cache the query result for this request. However, isVisible is called /before/ the ajax listener is called. Therefore any changes to the grid (like rowCount) are not used. Regards, Erik. Erik van Oosten wrote: Hi, How can I trigger an inmethod grid to do a /complete/ update of itself? The only thing that I see is markAllDirty(). That will update the items currently in the list, but it will /not/ get new items from the data provider. I researched the code for quite some time but I must have been looking at the wrong parts as I found no hook to get this done. The most I could do was call detach() on Body, one of the inner classes of a grid. But on screen, that would only update the number of items in the lower toolbar, not the items in the grid themselves. More ideas? Ideally, imho, the grid should respond to modelChanged(). But I have still no clue what should be in that method. Regards, Erik. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ -- View this message in context: http://www.nabble.com/Updating-an-inmethod-grid%2C-looking-for-hints-tp24438566p24624631.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Updating an inmethod grid, looking for hints
Sorry, please ignore my previous e-mail. The behavior I saw was due to a DropDownChoice I added to the toolbar. During a submit Wicket verifies whether the ddc is visible. Unfortunately this leads to a call to PagingToolbar.isVisible. Back to square 1. Regards, Erik. On Thu, 23 Jul 2009 05:20:06 -0700 (PDT), Erik van Oosten e.vanoos...@grons.nl wrote: Hi Matej, I finally found the bug. When you are using a DefaultDataGrid it adds a PagingToolbar. PagingToolbar overrides isVisible. In isVisible the total row count is determined, this will cache the query result for this request. However, isVisible is called /before/ the ajax listener is called. Therefore any changes to the grid (like rowCount) are not used. Regards, Erik. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: how to strip wicket tags for particular component
Turning the 2 lines around might give better results.
Regards,
Erik.
Mathias Nilsson wrote:
What about
@Override
public void onComponentTag( ComponentTag tag){
tag.remove( wicket:id );
super.onComponentTag(tag);
}
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: what is wicket
Hello Gerald, You can find much of this kind of information on http://wicket.apache.org. Regards, Erik. On Tue, 14 Jul 2009 18:21:16 +0530, Gerald Fernando gerald.anto.ferna...@gmail.com wrote: Hello Friends, Am Gerald, new to wicket. can anyone say about wicket and advantages over other technologies it is very useful to my next step. please help me ThanksRegards, Gerald A - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: MixedHybridUrlCodingStrategy wanted
Hi Vladimir, You are right. Now I look at it, it is clearly more complex then I remembered. You can get my version here: http://pastie.org/543892 Regards, Erik. Vladimir K wrote: I didn't find it easy to do it myself. By easy I mean what I can accomplish within 15 mins. From the first glance it looks just like a mix of two strategies but it actually does not. MixedHybridUrlCodingStrategy should handle all the parameters delimited by slashes and some of them have names omitted. Original Mixed strategy operates with regular parameters syntax. I believe it would take some hours to study what strategies do internally and implement and test mixed solution. I hoped someone have already tried that. Unfortunately I didn't find anything by google and nabble so I posted the question here. If you could point me some old discussion I'd appreciate. Erik van Oosten wrote: It is fairly easy to construct it yourself. Just look at the code of MixedParamUrlCodingStrategy, copy it and replace the class you're extending to the corresponding HybridUrlCodingStrategy. Its also on the mailing list, search the archives. Lastly, the annotation based mounting project (forgot the name) contains it. Regards, Erik. Vladimir Kovalyuk wrote: Is there a worked combination of HybridUrlCodingStrategy and MixedParamUrlCodingStrategy? What is missed in the latter is ability to stay bookmarkable after reaction on actions. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: intercept security check in wicket-auth-roles
You don't have to use the spring xml config files to use Sprint Security. Just instantiate the beans from code! There is a small catch, you'll need to know something about Spring callbacks. These are some interface that Spring will automatically call. These are: InitializingBean, BeanNameAware, BeanFactoryAware and ApplicationContextAware. Hopefully Spring Security does not depend on them. But there are other options like jsecurity and lots of options on http://wicketstuff.org/confluence/display/STUFFWIKI/Wiki. Regards, Erik. Brill Pappin wrote: Thanks for the heads up. I'll have to look at the security project again, but one thing I really like about auth-roles is that is so amazingly simply to deploy... however, I don't use spring (I'm a detractors of frameworks that use metadata where code should be) so I don't think its going to be any use to me here. - Brill On 11-Jul-09, at 3:47 AM, Olger Warnier wrote: The wicket-security framework has possibilities to integrate with SSO mechanisms. Next to that, you can integrate with spring-security and all authentication mechanisms supported by that. The yahoo-bbauth sample may help you to get an idea on how that works. Olger On 11 jul 2009, at 08:09, Brill Pappin wrote: I actually find it very usable and i love how simple it is... does the new security framework have a similar simple method of securing a site like that? - Brill On 3-Jul-09, at 11:34 AM, Igor Vaynberg wrote: wicket auth roles is an example, not a reusable framework. you should copy and paste the code into your project and customize as needed. -igor On Fri, Feb 20, 2009 at 8:30 AM, Brill Pappinbr...@pappin.ca wrote: I'm trying to integrate wicket-auth-roles with a token based SSO security system. I can't see where I can intercept the authentication sequence and auto-login the user based on the token. Essentially i want to catch the authentication request and authorize the user based on a token before they are redirected to the login page. Does anyone have a clue how I might go about doing that? Unfortunately most places I've looked to over ride the sequence are marked final for some reason, which makes things difficult. I'm actually at the point now where I'm thinking of writing a new auth-roles based on the current lib, but I thought I'd ask first. ... and no, I don't want to use the other more complex security lib... auth-roles is very nice and simple to use and suitable for most applications. - Brill Pappin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: MixedHybridUrlCodingStrategy wanted
Please do :) Erik. Vladimir K wrote: Thanks very much! Why not suggest it as a patch to wicket core? Erik van Oosten wrote: Hi Vladimir, You are right. Now I look at it, it is clearly more complex then I remembered. You can get my version here: http://pastie.org/543892 Regards, Erik. Vladimir K wrote: I didn't find it easy to do it myself. By easy I mean what I can accomplish within 15 mins. From the first glance it looks just like a mix of two strategies but it actually does not. MixedHybridUrlCodingStrategy should handle all the parameters delimited by slashes and some of them have names omitted. Original Mixed strategy operates with regular parameters syntax. I believe it would take some hours to study what strategies do internally and implement and test mixed solution. I hoped someone have already tried that. Unfortunately I didn't find anything by google and nabble so I posted the question here. If you could point me some old discussion I'd appreciate. Erik van Oosten wrote: It is fairly easy to construct it yourself. Just look at the code of MixedParamUrlCodingStrategy, copy it and replace the class you're extending to the corresponding HybridUrlCodingStrategy. Its also on the mailing list, search the archives. Lastly, the annotation based mounting project (forgot the name) contains it. Regards, Erik. Vladimir Kovalyuk wrote: Is there a worked combination of HybridUrlCodingStrategy and MixedParamUrlCodingStrategy? What is missed in the latter is ability to stay bookmarkable after reaction on actions. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: model detached many times
As models are nested this is not possible with the current setup. If a model nests another model, the nesting model is responsible for calling detach on the nested model. Multiple models may nest the same model. So the best thing to do for now is to have some flag to see if you're already detached. In getObject the flag is cleared. For most models however, it should not matter if they're called multiple times; the typical thing you do in detach is set a field to null. Regards, Erik. James Carman wrote: No, he means *all* models. The idea would be that Wicket would look for fields of type IModel (or its descendants) on components/pages. If it sees one, it would automatically detach it. On Mon, Jul 13, 2009 at 3:47 AM, Vladimir Kkoval...@gmail.com wrote: Martijn, you probably mean how chained models would be detached. So instead of propagating detach in IChainedModel they would be detached automatically? Is there a vision how it would be accomplished? Martijn Dashorst wrote: Automatic detachment is one of the things we're looking into for 1.5 or 1.6 Martijn On Fri, Jul 10, 2009 at 12:47 PM, James Carmanjcar...@carmanconsulting.com wrote: Perhaps there could be some sort of registry for models that need to be detached. Then, after rendering, they're all detached as part of the request cycle? On Fri, Jul 10, 2009 at 4:00 AM, Martijn Dashorstmartijn.dasho...@gmail.com wrote: If you share a model between components, then yes–each component will call detach on the model. That's encapsulation for you: one component doesn't know about another component, so it can't know that its model was detached. Martijn On Fri, Jul 10, 2009 at 9:41 AM, Ian MacLartyian.macla...@gmail.com wrote: I put a breakpoint on the detach method of my model and had a look at the Components whose detach methods were called higher up in the stack trace. It looks like the detach method on the model is being called for every component on the page. All the components link to the same underlying model via a CompoundPropertyModel, so I guess lots of calls to the detach method of the model should be expected? Ian. On Fri, Jul 10, 2009 at 5:17 PM, Eelco Hilleniuseelco.hillen...@gmail.com wrote: It's fine if a model if detached multiple times in a request, but hundreds for a single model sounds suspicious. Try to trace what components fire the detach method and see if there's anything weird with that. Eelco On Thu, Jul 9, 2009 at 11:21 PM, Ian MacLartyian.macla...@gmail.com wrote: Hi, I noticed that my IDetachable model is being detached many times (hundreds) for each request. Is that something to worry about, or is it just because the detach method is called for each component that points to this model? Ian. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Updating an inmethod grid, looking for hints
Hi Matej, I just got a hint from a colleague: it might has something to do with returning the wrong number of items in the dataprovider query. We probably return UNDEFINED too often. I'll look further into it. Regards, Erik. Erik van Oosten wrote: DataGrid. DefaultDataGrid mostly. Erik. Matej Knopp schreef: are you using treegrid or datagrid? -Matej On Sat, Jul 11, 2009 at 1:43 PM, Erik van Oostene.vanoos...@grons.nl wrote: If I remember correctly that only updates the existing items and ignore new items. I am looking for a way to get the new items too. Regards, Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: MixedHybridUrlCodingStrategy wanted
It is fairly easy to construct it yourself. Just look at the code of MixedParamUrlCodingStrategy, copy it and replace the class you're extending to the corresponding HybridUrlCodingStrategy. Its also on the mailing list, search the archives. Lastly, the annotation based mounting project (forgot the name) contains it. Regards, Erik. Vladimir Kovalyuk wrote: Is there a worked combination of HybridUrlCodingStrategy and MixedParamUrlCodingStrategy? What is missed in the latter is ability to stay bookmarkable after reaction on actions. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Updating an inmethod grid, looking for hints
Hi, How can I trigger an inmethod grid to do a /complete/ update of itself? The only thing that I see is markAllDirty(). That will update the items currently in the list, but it will /not/ get new items from the data provider. I researched the code for quite some time but I must have been looking at the wrong parts as I found no hook to get this done. The most I could do was call detach() on Body, one of the inner classes of a grid. But on screen, that would only update the number of items in the lower toolbar, not the items in the grid themselves. More ideas? Ideally, imho, the grid should respond to modelChanged(). But I have still no clue what should be in that method. Regards, Erik. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Updating an inmethod grid, looking for hints
DataGrid. DefaultDataGrid mostly. Erik. Matej Knopp schreef: are you using treegrid or datagrid? -Matej On Sat, Jul 11, 2009 at 1:43 PM, Erik van Oostene.vanoos...@grons.nl wrote: If I remember correctly that only updates the existing items and ignore new items. I am looking for a way to get the new items too. Regards, Erik. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
