[jira] [Closed] (TAP5-1730) Ajax Zone is improperly reloaded when a mixin submits form via JavaScript
[ https://issues.apache.org/jira/browse/TAP5-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lenny Primak closed TAP5-1730. -- Resolution: Fixed Fix Version/s: 5.4 Since form submission was rewritten in 5.4, there is no need to call submit directly, so this problem is gone > Ajax Zone is improperly reloaded when a mixin submits form via JavaScript > - > > Key: TAP5-1730 > URL: https://issues.apache.org/jira/browse/TAP5-1730 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.3, 5.4 >Reporter: Lenny Primak >Priority: Minor > Fix For: 5.4 > > > Tapestry reloads the zone improperly if JS code > Improperly submits the form. It should at least give some kind of an error > or a warning when happens. > Right now, it fails silently leading to an improper zone reload, > which leads to weird errors when app is running subsequently. > If form..setSubmittingElement(() isn't called before form.onsubmit(), > the Tapestry silently fails and the zone is improperly reloaded. > --- > There was an addition of one line: > $(this.formId).setSubmittingElement($(this.elementId)); // *** ADDED > otherwise zone gets improperly reloaded > $(this.formId).onsubmit(); // Submit Ajax form > If you don't add the first line, the form is reloaded improperly after the > zone update, > so it doesn't work the second time. > This is not documented anywhere, and really hard to debug. > See threads: > http://mail-archives.apache.org/mod_mbox/tapestry-users/201110.mbox/%3c21cb9971-ed77-4f37-9c72-501d0f513...@hope.nyc.ny.us%3E > http://tapestry.1045711.n5.nabble.com/Mixins-stop-working-after-a-zone-update-please-help-td4935912.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2175) Bean Validation fails when @Size(min) is not specified but max is specified
Lenny Primak created TAP5-2175: -- Summary: Bean Validation fails when @Size(min) is not specified but max is specified Key: TAP5-2175 URL: https://issues.apache.org/jira/browse/TAP5-2175 Project: Tapestry 5 Issue Type: Bug Components: tapestry-beanvalidator Affects Versions: 5.4 Reporter: Lenny Primak Priority: Critical beanvalidator-validation.js has a bug in rangeValue() if(v===null) // should be if(v==null) In the current state, it will return undefined if @Size(min) is not present, thus failing for perfectly valid input -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2174) Add main method the Jetty7Runner
Barry Books created TAP5-2174:
-
Summary: Add main method the Jetty7Runner
Key: TAP5-2174
URL: https://issues.apache.org/jira/browse/TAP5-2174
Project: Tapestry 5
Issue Type: New Feature
Components: tapestry-test
Affects Versions: 5.4
Reporter: Barry Books
Priority: Minor
Please add a main method to Jetty7Runner (really in tapestry-runner) so Jetty
can easily be started from an IDE development environment. Something like
public static void main(String[] args) throws Exception {
String webapp = System.getProperty("webapp") == null ?
"src/main/webapp" : System.getProperty("webapp");
String context = System.getProperty("context") == null ? "/" :
System.getProperty("context");
String httpPort = System.getProperty("httpPort") == null ?
"8080" : System.getProperty("httpPort");
String sslPort = System.getProperty("sslPort") == null ? "8443"
: System.getProperty("sslPort");
new Jetty7Runner(webapp, context, new Integer(httpPort), new
Integer(sslPort));
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2173) Tapestry DateField converts invalid dates to valid ones.
Barry Books created TAP5-2173: - Summary: Tapestry DateField converts invalid dates to valid ones. Key: TAP5-2173 URL: https://issues.apache.org/jira/browse/TAP5-2173 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Barry Books The combination of the DateField component and the conversion of strings to SimpleDateFormat result in the DateField converting invalid dates to valid ones. There are really two problems. The default for SimpleDateFormat is lenient so strings are converted with lenient set to true. This causes the date conversion to changes dates like 9/32/2013 to Wed Oct 02 00:00:00 CDT 2013. The second problem is DateField allows extra characters after the valid part of the date. For example 9/01/2013 converts to Sun Sep 01 00:00:00 CDT 2013. This is more of a problem with formats such as -MM-dd because a date such as 2013-09-061 is allowed and converted to Thu Oct 31 00:00:00 CDT 2013. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2172) ComponentClassResolver does not resolve logical name to the more intuitive component
Olivier Le Merdy created TAP5-2172: -- Summary: ComponentClassResolver does not resolve logical name to the more intuitive component Key: TAP5-2172 URL: https://issues.apache.org/jira/browse/TAP5-2172 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.3.7 Reporter: Olivier Le Merdy Priority: Minor ComponentClassResolver does not always resolve components the more intuitive way. See attached sample project for demonstration purposes but given a set of three components: "foo/Bar", "foo/FooBar" and "foo/BarFoo", the logical name "foo/bar" will be resolved to "foo/FooBar" component instead of the more intuitive "foo/Bar". The workaround is to rename our components but, given the stripping can happen at multiple package levels, it is sometimes hard to predict (and debug) what is happening, e.g.: "layout/detail/Section" logical name will resolve primarily "layout/detail/SectionLayout" component instead of "layout/detail/Section" component. Looking at ComponentClassResolverImpl implementation, the component name cache is filled following classpath alphabetical order, overriding any previous entry found. Could it be possible to privilege a component when its unstripped name exactly match its logical name? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-2172) ComponentClassResolver does not resolve logical name to the more intuitive component
[ https://issues.apache.org/jira/browse/TAP5-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Le Merdy updated TAP5-2172: --- Attachment: bug-sample.zip Bug sample project > ComponentClassResolver does not resolve logical name to the more intuitive > component > > > Key: TAP5-2172 > URL: https://issues.apache.org/jira/browse/TAP5-2172 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.3.7 >Reporter: Olivier Le Merdy >Priority: Minor > Attachments: bug-sample.zip > > > ComponentClassResolver does not always resolve components the more intuitive > way. > See attached sample project for demonstration purposes but given a set of > three components: "foo/Bar", "foo/FooBar" and "foo/BarFoo", the logical name > "foo/bar" will be resolved to "foo/FooBar" component instead of the more > intuitive "foo/Bar". > The workaround is to rename our components but, given the stripping can > happen at multiple package levels, it is sometimes hard to predict (and > debug) what is happening, e.g.: "layout/detail/Section" logical name will > resolve primarily "layout/detail/SectionLayout" component instead of > "layout/detail/Section" component. > Looking at ComponentClassResolverImpl implementation, the component name > cache is filled following classpath alphabetical order, overriding any > previous entry found. > Could it be possible to privilege a component when its unstripped name > exactly match its logical name? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-2171) LinkSubmit Broken With Client-side Validation
Peter H created TAP5-2171: - Summary: LinkSubmit Broken With Client-side Validation Key: TAP5-2171 URL: https://issues.apache.org/jira/browse/TAP5-2171 Project: Tapestry 5 Issue Type: Bug Affects Versions: 5.4 Reporter: Peter H This was confirmed on the mailing list by one other user of 5.4 alpha 15. Example tml; http://tapestry.apache.org/schema/tapestry_5_3.xsd";> Bob Link Submit Example java; @Property private String bob_; Clicking the linksubmit causes a POST regardless of the client-side validation on textfield bob, and when the page reloads we see the validation message. Clicking the submit causes no POST and client-side validation appears immediately. Thanks! Peter -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
