[jira] [Updated] (TAP5-1523) Dutch validation messages
[ https://issues.apache.org/jira/browse/TAP5-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost Schouten updated TAP5-1523: - Attachment: Palette_nl.properties Dutch validation messages - Key: TAP5-1523 URL: https://issues.apache.org/jira/browse/TAP5-1523 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.5 Reporter: Joost Schouten Attachments: BeanEditForm_nl.properties, Errors_nl.properties, GridColumns_nl.properties, GridPager_nl.properties, Palette_nl.properties, ValidationMessages_nl.properties I would like to see the Dutch validation messages added. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1523) Dutch validation messages
[ https://issues.apache.org/jira/browse/TAP5-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost Schouten updated TAP5-1523: - Attachment: GridPager_nl.properties Dutch validation messages - Key: TAP5-1523 URL: https://issues.apache.org/jira/browse/TAP5-1523 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.5 Reporter: Joost Schouten Attachments: BeanEditForm_nl.properties, Errors_nl.properties, GridColumns_nl.properties, GridPager_nl.properties, Palette_nl.properties, ValidationMessages_nl.properties I would like to see the Dutch validation messages added. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1523) Dutch validation messages
[ https://issues.apache.org/jira/browse/TAP5-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost Schouten updated TAP5-1523: - Attachment: BeanEditForm_nl.properties Dutch validation messages - Key: TAP5-1523 URL: https://issues.apache.org/jira/browse/TAP5-1523 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.5 Reporter: Joost Schouten Attachments: BeanEditForm_nl.properties, Errors_nl.properties, GridColumns_nl.properties, GridPager_nl.properties, Palette_nl.properties, ValidationMessages_nl.properties I would like to see the Dutch validation messages added. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1523) Dutch validation messages
[ https://issues.apache.org/jira/browse/TAP5-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost Schouten updated TAP5-1523: - Attachment: GridColumns_nl.properties Dutch validation messages - Key: TAP5-1523 URL: https://issues.apache.org/jira/browse/TAP5-1523 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.5 Reporter: Joost Schouten Attachments: BeanEditForm_nl.properties, Errors_nl.properties, GridColumns_nl.properties, GridPager_nl.properties, Palette_nl.properties, ValidationMessages_nl.properties I would like to see the Dutch validation messages added. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1523) Dutch validation messages
[ https://issues.apache.org/jira/browse/TAP5-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost Schouten updated TAP5-1523: - Attachment: Errors_nl.properties Dutch validation messages - Key: TAP5-1523 URL: https://issues.apache.org/jira/browse/TAP5-1523 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.5 Reporter: Joost Schouten Attachments: BeanEditForm_nl.properties, Errors_nl.properties, GridColumns_nl.properties, GridPager_nl.properties, Palette_nl.properties, ValidationMessages_nl.properties I would like to see the Dutch validation messages added. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1523) Dutch validation messages
[ https://issues.apache.org/jira/browse/TAP5-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071004#comment-13071004 ] Joost Schouten commented on TAP5-1523: -- I added the other translations as well. Dutch validation messages - Key: TAP5-1523 URL: https://issues.apache.org/jira/browse/TAP5-1523 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.5 Reporter: Joost Schouten Attachments: BeanEditForm_nl.properties, Errors_nl.properties, GridColumns_nl.properties, GridPager_nl.properties, Palette_nl.properties, ValidationMessages_nl.properties I would like to see the Dutch validation messages added. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1523) Dutch validation messages
[ https://issues.apache.org/jira/browse/TAP5-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost Schouten updated TAP5-1523: - Attachment: tapestry-kaptcha_nl.properties Dutch validation messages - Key: TAP5-1523 URL: https://issues.apache.org/jira/browse/TAP5-1523 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.5 Reporter: Joost Schouten Attachments: BeanEditForm_nl.properties, Errors_nl.properties, GridColumns_nl.properties, GridPager_nl.properties, Palette_nl.properties, ValidationMessages_nl.properties, tapestry-kaptcha_nl.properties I would like to see the Dutch validation messages added. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1523) Dutch validation messages
[ https://issues.apache.org/jira/browse/TAP5-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost Schouten updated TAP5-1523: - Attachment: tapestry-kaptcha_nl.properties Dutch validation messages - Key: TAP5-1523 URL: https://issues.apache.org/jira/browse/TAP5-1523 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.5 Reporter: Joost Schouten Attachments: BeanEditForm_nl.properties, Errors_nl.properties, GridColumns_nl.properties, GridPager_nl.properties, Palette_nl.properties, ValidationMessages_nl.properties, tapestry-kaptcha_nl.properties I would like to see the Dutch validation messages added. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1523) Dutch validation messages
[ https://issues.apache.org/jira/browse/TAP5-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost Schouten updated TAP5-1523: - Attachment: (was: tapestry-kaptcha_nl.properties) Dutch validation messages - Key: TAP5-1523 URL: https://issues.apache.org/jira/browse/TAP5-1523 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.5 Reporter: Joost Schouten Attachments: BeanEditForm_nl.properties, Errors_nl.properties, GridColumns_nl.properties, GridPager_nl.properties, Palette_nl.properties, ValidationMessages_nl.properties, tapestry-kaptcha_nl.properties I would like to see the Dutch validation messages added. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1523) Dutch validation messages
[ https://issues.apache.org/jira/browse/TAP5-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071060#comment-13071060 ] Joost Schouten commented on TAP5-1523: -- Added it to the attachments Dutch validation messages - Key: TAP5-1523 URL: https://issues.apache.org/jira/browse/TAP5-1523 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.5 Reporter: Joost Schouten Attachments: BeanEditForm_nl.properties, Errors_nl.properties, GridColumns_nl.properties, GridPager_nl.properties, Palette_nl.properties, ValidationMessages_nl.properties, tapestry-kaptcha_nl.properties I would like to see the Dutch validation messages added. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1533) File download breaks zone managers due to unload event
[ https://issues.apache.org/jira/browse/TAP5-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost Schouten updated TAP5-1533: - Description: When a file is downloaded the unload event does some cleanup which prevents subsequent AJAX responses to fail. The request and response work fine, just the javascript handeling of the returned JSON fails. Once the page is refreshed all works fine again. (was: When a file is downloaded the unload event does some cleanup which prevents subsequent AJAX responses to fail. The request and response work fine, just the javascript handeling of the returned JSON fails.) File download breaks zone managers due to unload event -- Key: TAP5-1533 URL: https://issues.apache.org/jira/browse/TAP5-1533 Project: Tapestry 5 Issue Type: Bug Components: tapestry-component-report Affects Versions: 5.2.5 Reporter: Joost Schouten When a file is downloaded the unload event does some cleanup which prevents subsequent AJAX responses to fail. The request and response work fine, just the javascript handeling of the returned JSON fails. Once the page is refreshed all works fine again. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-1533) File download breaks zone managers due to unload event
File download breaks zone managers due to unload event -- Key: TAP5-1533 URL: https://issues.apache.org/jira/browse/TAP5-1533 Project: Tapestry 5 Issue Type: Bug Components: tapestry-component-report Affects Versions: 5.2.5 Reporter: Joost Schouten When a file is downloaded the unload event does some cleanup which prevents subsequent AJAX responses to fail. The request and response work fine, just the javascript handeling of the returned JSON fails. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1523) Dutch validation messages
[ https://issues.apache.org/jira/browse/TAP5-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost Schouten updated TAP5-1523: - Attachment: ValidationMessages_nl.properties The first one had a small bug in that I forgot to add the %1 and %2 where I switched their order around. Dutch validation messages - Key: TAP5-1523 URL: https://issues.apache.org/jira/browse/TAP5-1523 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.5 Reporter: Joost Schouten Attachments: ValidationMessages_nl.properties I would like to see the Dutch validation messages added. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1523) Dutch validation messages
[ https://issues.apache.org/jira/browse/TAP5-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost Schouten updated TAP5-1523: - Attachment: (was: ValidationMessages_nl.properties) Dutch validation messages - Key: TAP5-1523 URL: https://issues.apache.org/jira/browse/TAP5-1523 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.5 Reporter: Joost Schouten Attachments: ValidationMessages_nl.properties I would like to see the Dutch validation messages added. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-1529) Allow an empty grid to print it's thead
Allow an empty grid to print it's thead --- Key: TAP5-1529 URL: https://issues.apache.org/jira/browse/TAP5-1529 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.5, 5.3 Reporter: Joost Schouten I'd like the ability to print the thead of a Grid even when the source is empty. Maybe this could be another block option that could be passed to the empty parameter. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1523) Dutch validation messages
[ https://issues.apache.org/jira/browse/TAP5-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost Schouten updated TAP5-1523: - Attachment: ValidationMessages_nl.properties here they are Dutch validation messages - Key: TAP5-1523 URL: https://issues.apache.org/jira/browse/TAP5-1523 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.2.5 Reporter: Joost Schouten Attachments: ValidationMessages_nl.properties I would like to see the Dutch validation messages added. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TAP5-1430) prevent property binding to itself
prevent property binding to itself -- Key: TAP5-1430 URL: https://issues.apache.org/jira/browse/TAP5-1430 Project: Tapestry 5 Issue Type: Bug Affects Versions: 5.2.4 Reporter: Joost Schouten It is currently possible to bind a property to itself like so: @Property @Parameter(value=actionZone) private String actionZone; This causes a StackOverflowError where it should just assign the default literal value actionZone to the property actionZone. Or it should complain and throw an Exception informing the developer that you cannot bind in this way without specifying the prefix literal: -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TAP5-1430) prevent property binding to itself
[ https://issues.apache.org/jira/browse/TAP5-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost Schouten updated TAP5-1430: - Component/s: tapestry-core prevent property binding to itself -- Key: TAP5-1430 URL: https://issues.apache.org/jira/browse/TAP5-1430 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.2.4 Reporter: Joost Schouten It is currently possible to bind a property to itself like so: @Property @Parameter(value=actionZone) private String actionZone; This causes a StackOverflowError where it should just assign the default literal value actionZone to the property actionZone. Or it should complain and throw an Exception informing the developer that you cannot bind in this way without specifying the prefix literal: -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TAP5-733) AjaxFormLoop occasionally fails with The rendered content did not include any elements that allow for the positioning of the hidden form field's element
[ https://issues.apache.org/jira/browse/TAP5-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12881151#action_12881151 ] Joost Schouten commented on TAP5-733: - Same here, I did have the problem and haven't seen it for a couple of months after switching to 5.2-SNAPSHOT. AjaxFormLoop occasionally fails with The rendered content did not include any elements that allow for the positioning of the hidden form field's element -- Key: TAP5-733 URL: https://issues.apache.org/jira/browse/TAP5-733 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Howard M. Lewis Ship First reported by the users at ProQuest and hard to reproduce. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1047) extending Autocomplete no longer works
extending Autocomplete no longer works -- Key: TAP5-1047 URL: https://issues.apache.org/jira/browse/TAP5-1047 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.2.0 Reporter: Joost Schouten Since february 20th 2 problems have been introduced when extending the Autocomplete mixin. - The mixin will try to load the autocomplete.js from the classpath location of the extending class, in stead of the Autocomplete.class - The @Override methods (eg. generateResponseMarkup(MarkupWriter writer, List matches)) are no longer called on the extending class I have been using my extended version for about 18 months without problems and suspect it might have something to do with the move away from javassist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-945) Unnecessary and severe lock contention in PerthreadManagerImpl
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12787966#action_12787966 ] Joost Schouten commented on TAP5-945: - I'm not quite sure if it is possible to run Tapestry5 on java 1.4 and if anyone does, but looking at the current code the DummyLock will be used with anything but java 1.5. Is that what you want? Should it not be; use DummyLock when java version 1.5? Unnecessary and severe lock contention in PerthreadManagerImpl -- Key: TAP5-945 URL: https://issues.apache.org/jira/browse/TAP5-945 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Olle Hallin Assignee: Howard M. Lewis Ship Priority: Minor Fix For: 5.2.0.0 When load testing our new high-volume site before soft launch, we found that we have severe lock contention in org.apache.tapestry5.ioc.internal.services.PerthreadManagerImpl. It synchronizes on this before invoking ThreadLocal.get() and ThreadLocal.remove(), which I believe is unnecessary. During our tests, approximately 35% of all Tomcat threads were waiting for this lock in any of 10 thread dumps taken 15 seconds apart. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-945) Unnecessary and severe lock contention in PerthreadManagerImpl
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12787972#action_12787972 ] Joost Schouten commented on TAP5-945: - that'll fix it then ;-) thx. Just wondered since the JDK bug was reported against 1.4. Unnecessary and severe lock contention in PerthreadManagerImpl -- Key: TAP5-945 URL: https://issues.apache.org/jira/browse/TAP5-945 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Olle Hallin Assignee: Howard M. Lewis Ship Priority: Minor Fix For: 5.2.0.0 When load testing our new high-volume site before soft launch, we found that we have severe lock contention in org.apache.tapestry5.ioc.internal.services.PerthreadManagerImpl. It synchronizes on this before invoking ThreadLocal.get() and ThreadLocal.remove(), which I believe is unnecessary. During our tests, approximately 35% of all Tomcat threads were waiting for this lock in any of 10 thread dumps taken 15 seconds apart. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-937) LinkImpl does not handle parameters propery when passed into the constructor
[ https://issues.apache.org/jira/browse/TAP5-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost Schouten updated TAP5-937: Attachment: (was: parameter_addition_patch.txt) LinkImpl does not handle parameters propery when passed into the constructor Key: TAP5-937 URL: https://issues.apache.org/jira/browse/TAP5-937 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1 Reporter: Joost Schouten I noticed this after using the AjaxFormLoop AddRowLink on a page which has an onActivate and onPassivate resulting in the addition of a t:ac to the url. Debugging showed me that the t:ac is already present on instantiation of the LinkImpl. When calling toAbsoluteUri the parameters are added in a way where they will always start with a ?. Obvisouly resulting in an invalid URL with two ?'s I'm building a failing test at this stage and will provide a patch once resolved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-937) LinkImpl does not handle parameters propery when passed into the constructor
[ https://issues.apache.org/jira/browse/TAP5-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost Schouten updated TAP5-937: Attachment: parameter_addition_patch.txt patch checks if the baseURI already contains a '?', if so start adding the new params with an '', otherwise start with a '?'. Also added a test for a situation where a base URI with parameters on the path in instantiated. LinkImpl does not handle parameters propery when passed into the constructor Key: TAP5-937 URL: https://issues.apache.org/jira/browse/TAP5-937 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1 Reporter: Joost Schouten Attachments: parameter_addition_patch.txt I noticed this after using the AjaxFormLoop AddRowLink on a page which has an onActivate and onPassivate resulting in the addition of a t:ac to the url. Debugging showed me that the t:ac is already present on instantiation of the LinkImpl. When calling toAbsoluteUri the parameters are added in a way where they will always start with a ?. Obvisouly resulting in an invalid URL with two ?'s I'm building a failing test at this stage and will provide a patch once resolved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-937) LinkImpl does not handle parameters propery when passed into the constructor
[ https://issues.apache.org/jira/browse/TAP5-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12783563#action_12783563 ] Joost Schouten commented on TAP5-937: - The problem only exists when using any UrlRewriteRule, activation context and additional parameters. The t:ac seems to be added to the URL before the UrlRewriting happens, where the AjaxFormLoop parameters seem to be added after the rewriting which results in the buildURI being called twice, causing the double questionmark. LinkImpl does not handle parameters propery when passed into the constructor Key: TAP5-937 URL: https://issues.apache.org/jira/browse/TAP5-937 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1 Reporter: Joost Schouten Attachments: parameter_addition_patch.txt I noticed this after using the AjaxFormLoop AddRowLink on a page which has an onActivate and onPassivate resulting in the addition of a t:ac to the url. Debugging showed me that the t:ac is already present on instantiation of the LinkImpl. When calling toAbsoluteUri the parameters are added in a way where they will always start with a ?. Obvisouly resulting in an invalid URL with two ?'s I'm building a failing test at this stage and will provide a patch once resolved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-937) LinkImpl does not handle parameters propery when passed into the constructor
LinkImpl does not handle parameters propery when passed into the constructor Key: TAP5-937 URL: https://issues.apache.org/jira/browse/TAP5-937 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1 Reporter: Joost Schouten I noticed this after using the AjaxFormLoop AddRowLink on a page which has an onActivate and onPassivate resulting in the addition of a t:ac to the url. Debugging showed me that the t:ac is already present on instantiation of the LinkImpl. When calling toAbsoluteUri the parameters are added in a way where they will always start with a ?. Obvisouly resulting in an invalid URL with two ?'s I'm building a failing test at this stage and will provide a patch once resolved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-937) LinkImpl does not handle parameters propery when passed into the constructor
[ https://issues.apache.org/jira/browse/TAP5-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost Schouten updated TAP5-937: Attachment: parameter_addition_patch.txt this patch will make sure that added parameters start with a ? when no params are available in the base uri yet, and a when parameters are already available. LinkImpl does not handle parameters propery when passed into the constructor Key: TAP5-937 URL: https://issues.apache.org/jira/browse/TAP5-937 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1 Reporter: Joost Schouten Attachments: parameter_addition_patch.txt I noticed this after using the AjaxFormLoop AddRowLink on a page which has an onActivate and onPassivate resulting in the addition of a t:ac to the url. Debugging showed me that the t:ac is already present on instantiation of the LinkImpl. When calling toAbsoluteUri the parameters are added in a way where they will always start with a ?. Obvisouly resulting in an invalid URL with two ?'s I'm building a failing test at this stage and will provide a patch once resolved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-742) Add optional component tracing comments to rendered output
[ https://issues.apache.org/jira/browse/TAP5-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12778261#action_12778261 ] Joost Schouten commented on TAP5-742: - +1 Unit testing is where is comes in handy. With the addition of the component class to te comment It will allow you to do things like assertComponentOnPage(MyComponent.class). Add optional component tracing comments to rendered output -- Key: TAP5-742 URL: https://issues.apache.org/jira/browse/TAP5-742 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Howard M. Lewis Ship Priority: Minor In complex pages, it can be hard to work backwards from a bit of output HTML in the browser, back to the component that originated the markup. A special mode could be enabled where components would render a comment before and after rendering: !-- BEGIN: Index:layout.pagelink -- a href=dashboardDashboard/a !-- END: Index:layout.pagelink -- This would bloat and clutter the application (a lot!) but would be useful, on occasion. One possibility would be a special query parameter to enable this on a request-by-request basis, i.e., ?t:component-trace=true -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-929) Implement sendRedirect() for TestableResponseImpl
Implement sendRedirect() for TestableResponseImpl
-
Key: TAP5-929
URL: https://issues.apache.org/jira/browse/TAP5-929
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-test
Reporter: Joost Schouten
When running my tests I would like my redirects to work so I can test that they
redirect to the correct destinations. In my case a SecurityDispatcher that
manages access rights for different users.
currently it throws a RuntimeException(TestableResponse: Method sendRedirect
not yet implemented.) at:
059public void sendRedirect(String URL) throws IOException
060{
061nyi(sendRedirect);
062}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-929) Implement sendRedirect() for TestableResponseImpl
[
https://issues.apache.org/jira/browse/TAP5-929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12777447#action_12777447
]
Joost Schouten commented on TAP5-929:
-
a workaround for now is to use sendRedirect(Link) in your code in stead of
sendRedirect(String url) as this is implemented.
Implement sendRedirect() for TestableResponseImpl
-
Key: TAP5-929
URL: https://issues.apache.org/jira/browse/TAP5-929
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-test
Reporter: Joost Schouten
When running my tests I would like my redirects to work so I can test that
they redirect to the correct destinations. In my case a SecurityDispatcher
that manages access rights for different users.
currently it throws a RuntimeException(TestableResponse: Method sendRedirect
not yet implemented.) at:
059public void sendRedirect(String URL) throws IOException
060{
061nyi(sendRedirect);
062}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-721) missing message key fail with exception
[ https://issues.apache.org/jira/browse/TAP5-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12714694#action_12714694 ] Joost Schouten commented on TAP5-721: - I just started looking for a way on how to make this work and have an architecture question. The logic to handle a missing key message or exception lives in AbstractMessages and is quite straight forward. Adding a boolean field exceptionOnMissingKey which defaults to false and providing an extra constructor taking both the Locale and this boolean. The tricky part however is that all Messages are instantiated using a static forClass() method which obviously cant pass any System property like this one along. In my oppinion this only leaves me with the option of making the exceptionOnMissingKey a static field and setting it in the TapestryModule, depending on SymbolConstant.EXCEPTION_ON_MISSING_KEY == true. I don't particularly like the idea of a static field though and can imagine more people with me. So my question; What would be the best way to go about this problem? Is there a singleton service we can always asume present for all of Tapestry which could be accessed by the AbstractMessages? Or would there need to be a complete rethink of how Messages are instantiated in order to cater for Exceptions on missing keys? Cheers, Joost missing message key fail with exception --- Key: TAP5-721 URL: https://issues.apache.org/jira/browse/TAP5-721 Project: Tapestry 5 Issue Type: Improvement Affects Versions: 5.2 Reporter: Joost Schouten I would like a way to tell tapestry to thrown an exception on encountering a missing message key. Printing of the missing key message on the page results in silent failure especially for larger apps. I would propose adding a boolean symbol along the lines of MISSING_MESSAGE_KEY_FAIL_WITH_EXCEPTION which defaults to false. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-721) missing message key fail with exception
missing message key fail with exception --- Key: TAP5-721 URL: https://issues.apache.org/jira/browse/TAP5-721 Project: Tapestry 5 Issue Type: Improvement Affects Versions: 5.2 Reporter: Joost Schouten I would like a way to tell tapestry to thrown an exception on encountering a missing message key. Printing of the missing key message on the page results in silent failure especially for larger apps. I would propose adding a boolean symbol along the lines of MISSING_MESSAGE_KEY_FAIL_WITH_EXCEPTION which defaults to false. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-587) Update of Loop in Zone in Form
Update of Loop in Zone in Form -- Key: TAP5-587 URL: https://issues.apache.org/jira/browse/TAP5-587 Project: Tapestry 5 Issue Type: Bug Reporter: Joost Schouten -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-587) Ajax update of volatile Loop in Zone in Form causes issues on Form submit
[
https://issues.apache.org/jira/browse/TAP5-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joost Schouten updated TAP5-587:
Component/s: tapestry-core
Description:
When a volatile Loop in a form gets updated through Ajax and results in having
less source items than on initial page render, a
java.util.NoSuchElementException (see below) because the Loop seems to think
there are more source items then there are. The whole volatile setting on a
loop is kind of unclear to me but I suspect it is intended for a Loop in a form
that holds Form Input. In my usecase the Form is just to display non-form data.
If my assumption is correct, I miss a parameter on the form like
noFormDataLoop, to tell the loop to ignore the complete Loop for state saving.
When I add if(iterator.hasNext()) to the advanceVolatile() method like below,
my usecase works again. I am unsure however if this would interfere with other
usecases. All unit tests still work which gives me hope this simple solution
might be included.
private void advanceVolatile()
{
if(iterator.hasNext())
value = iterator.next();
startHeartbeat();
}
I would love to get some input on if my assumptions are right and if my
proposed solutions might work. If so, I'll go ahead and build a patch.
Cheers,
Joost
- the exception on Form submit with volatile=true on Loop and Loop item
substraction through AJAX --
Caused by: java.util.NoSuchElementException
at java.util.AbstractList$Itr.next(AbstractList.java:427)
at
org.apache.tapestry5.corelib.components.Loop.advanceVolatile(Loop.java:335)
at org.apache.tapestry5.corelib.components.Loop.access$200(Loop.java:41)
at org.apache.tapestry5.corelib.components.Loop$3.execute(Loop.java:92)
at org.apache.tapestry5.corelib.components.Loop$3.execute(Loop.java:96)
at
org.apache.tapestry5.corelib.components.Form.executeStoredActions(Form.java:471)
... 81 more
Affects Version/s: 5.1.0.2
5.1.0.0
5.1.0.1
Summary: Ajax update of volatile Loop in Zone in Form causes
issues on Form submit (was: Update of Loop in Zone in Form)
Ajax update of volatile Loop in Zone in Form causes issues on Form submit
-
Key: TAP5-587
URL: https://issues.apache.org/jira/browse/TAP5-587
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.1.0.0, 5.1.0.1, 5.1.0.2
Reporter: Joost Schouten
When a volatile Loop in a form gets updated through Ajax and results in
having less source items than on initial page render, a
java.util.NoSuchElementException (see below) because the Loop seems to think
there are more source items then there are. The whole volatile setting on a
loop is kind of unclear to me but I suspect it is intended for a Loop in a
form that holds Form Input. In my usecase the Form is just to display
non-form data. If my assumption is correct, I miss a parameter on the form
like noFormDataLoop, to tell the loop to ignore the complete Loop for state
saving.
When I add if(iterator.hasNext()) to the advanceVolatile() method like below,
my usecase works again. I am unsure however if this would interfere with
other usecases. All unit tests still work which gives me hope this simple
solution might be included.
private void advanceVolatile()
{
if(iterator.hasNext())
value = iterator.next();
startHeartbeat();
}
I would love to get some input on if my assumptions are right and if my
proposed solutions might work. If so, I'll go ahead and build a patch.
Cheers,
Joost
- the exception on Form submit with volatile=true on Loop and Loop
item substraction through AJAX --
Caused by: java.util.NoSuchElementException
at java.util.AbstractList$Itr.next(AbstractList.java:427)
at
org.apache.tapestry5.corelib.components.Loop.advanceVolatile(Loop.java:335)
at
org.apache.tapestry5.corelib.components.Loop.access$200(Loop.java:41)
at org.apache.tapestry5.corelib.components.Loop$3.execute(Loop.java:92)
at org.apache.tapestry5.corelib.components.Loop$3.execute(Loop.java:96)
at
org.apache.tapestry5.corelib.components.Form.executeStoredActions(Form.java:471)
... 81 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-584) Omit genrator meta when root element is not html
Omit genrator meta when root element is not html Key: TAP5-584 URL: https://issues.apache.org/jira/browse/TAP5-584 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.2 Reporter: Joost Schouten Priority: Minor When using tapestry to generate xml which is not xhtml, the generator meta should be omitted. Currently tapestry will add a head and generator meta to every root element if the SymbolConstants.OMIT_GENERATOR_META == false. Solution: check if the root element name is html, if not, don't add even with SymbolConstants.OMIT_GENERATOR_META == false. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-584) Omit genrator meta when root element is not html
[ https://issues.apache.org/jira/browse/TAP5-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joost Schouten updated TAP5-584: Attachment: TAP-584_patch.txt Patch fixing the problem. Also added a test to check that the head and meta are not added if the root element is not html Omit genrator meta when root element is not html Key: TAP5-584 URL: https://issues.apache.org/jira/browse/TAP5-584 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.2 Reporter: Joost Schouten Priority: Minor Attachments: TAP-584_patch.txt When using tapestry to generate xml which is not xhtml, the generator meta should be omitted. Currently tapestry will add a head and generator meta to every root element if the SymbolConstants.OMIT_GENERATOR_META == false. Solution: check if the root element name is html, if not, don't add even with SymbolConstants.OMIT_GENERATOR_META == false. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-108) ActionLink should be able to update several zones
[ https://issues.apache.org/jira/browse/TAP5-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672111#action_12672111 ] Joost Schouten commented on TAP5-108: - Just to share a thought: I build a MultipleZoneUpdater Mixin which has been doing the job nicely for a while now. I just do everything the normal way, but Mix-in my Mixin on a component that contains the trigger that needs to update extra zone's and the zone's that need to be updated. From the parameters below you can understand the way I use it. If intrested I can add the whole code and js file later. What I really like about it is that it Allows an easy way to wire up any block to any zone on any js event. In the case you wire it up to a Zone,the other zones will update once that one is done, which is needed beacause often you want a CRUD action to be completed before another zone is updated. Anyway, just my 2 cents. /** * A Map of Zone id's mapped to the Block id's to update the zone */ @Parameter(required = true) private MapString, String zoneBlocks; /** * A comma seperated list of css identifiers of all elements that should trigger the * multiple zone update. All identifiers will update all passed zoneBlocks * in case of an a: onmouseup * in case of a zone: once loaded * in case of a form: onsubmit */ @Property @Parameter(required = true, defaultPrefix = literal) private String zoneTriggerCssIdentifiers; ActionLink should be able to update several zones - Key: TAP5-108 URL: https://issues.apache.org/jira/browse/TAP5-108 Project: Tapestry 5 Issue Type: Improvement Affects Versions: 5.0.15 Reporter: Igor Drobiazko Unfortunately the ActionLink's parameter zone expect a single zone. Commonly, we want to update several parts of the client. It would be very nice to be able to update a bunch of zones after an action was triggered. This limitation is quite frustrating for people coming from T4 because updateComponents expected a list of component ids. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-486) Switch Tapestry's built-in JavaScript support from Prototype to jQuery
[ https://issues.apache.org/jira/browse/TAP5-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669197#action_12669197 ] Joost Schouten commented on TAP5-486: - A switch would mean a lot of work on a few project for me too. So a switch would not get my vote. One thing that I would find interesting is to change the tapestry.js, and some of the other included *.js files into an thin interface like wrapper that does not rely on any framework. Then pull out all javascript into a seperate module and contribute the javascript module of your choice. This way nothing needs to change from the way it currently works with prototype (assuming prototype as the default), but it does allow to plug in any other framework, like jQuery or MooTools. Martin Reurings actually proposed a similair solution back in 2007 http://mail-archives.apache.org/mod_mbox/tapestry-dev/200710.mbox/%3cof6624565c.dad9ba14-onc1257369.00426459-c1257369.00440...@porsche.co.at%3e Cheers, Joost Switch Tapestry's built-in JavaScript support from Prototype to jQuery -- Key: TAP5-486 URL: https://issues.apache.org/jira/browse/TAP5-486 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.0 Reporter: Howard M. Lewis Ship Like rats deserting a sinking ship ... This is not a definitive requirement; I've created this issue to promote discussion. It's quite likely that a move like this could be accomplished quite smoothly for users who are meerly consumers of JavaScript components; authors of JavaScript components would have to make some changes. Possibly we should code the jQuery stack from the get-go to NOT use the $() method, but instead use j$(). That extra character to type could make all the difference is allowing a smooth upgrade, where jQuery becomes the default, but prototype/scriptaculous can still be used. Possibly a new annotation, @PrototypeSupport for components to ensure that the Prototype libraries are available for compatibility? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-418) More flexible Link URI manipulation for use in LinkCreationListener
[ https://issues.apache.org/jira/browse/TAP5-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12664087#action_12664087 ] Joost Schouten commented on TAP5-418: - But there doesn't seem to be a way to alter the actual URI on the Link instance passed to the Listner. The API only allows for adding Anchors or parameters. I would love to see a method on the Link interface that allows me full control over the URI. More flexible Link URI manipulation for use in LinkCreationListener --- Key: TAP5-418 URL: https://issues.apache.org/jira/browse/TAP5-418 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1 Reporter: Joost Schouten I would like to propose an extension of the Link interface with a setAbsoluteURI(String absoluteURI) method, or something alike. This will give more flexibility when handling the link in the LinkCreationListener. In my usecase, where I need the locale of the browser displayed as the first part of the URI (eg http://domain.com/en_US/myPage), I use a dispatcher to detect the locale (or change to it), and have to completely copy the LinkFactoryImpl into my own LocaleAwareLinkFactory (which gets contributed as an alias) to be able to set the URI to what I want on Link instantiation. If I can change the URI at a later stage I only need to add my own LinkCreationListener. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
