svn commit: r1304190 - /tapestry/tapestry5/trunk/tapestry-hibernate/build.gradle
Author: kaosko
Date: Fri Mar 23 05:08:59 2012
New Revision: 1304190
URL: http://svn.apache.org/viewvc?rev=1304190&view=rev
Log:
Upgrade hibernate dependency to 4.1.1 as discussed on the dev list
(http://markmail.org/thread/3nhpl5cptec4hfgf)
hibernate 4.1.1 has a hard dependency on jboss-logging, add
update hsqldb from 1.8.0.10 to 2.2.8, otherwise hsqldb throws "This function is
not supported"
Modified:
tapestry/tapestry5/trunk/tapestry-hibernate/build.gradle
Modified: tapestry/tapestry5/trunk/tapestry-hibernate/build.gradle
URL:
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-hibernate/build.gradle?rev=1304190&r1=1304189&r2=1304190&view=diff
==
--- tapestry/tapestry5/trunk/tapestry-hibernate/build.gradle (original)
+++ tapestry/tapestry5/trunk/tapestry-hibernate/build.gradle Fri Mar 23
05:08:59 2012
@@ -3,10 +3,11 @@ description = "Provides support for simp
dependencies {
compile project(':tapestry-core')
compile project(':tapestry-hibernate-core')
+ compile "org.jboss.logging:jboss-logging:3.1.0.GA"
testCompile project(':tapestry-test')
- testRuntime "org.hsqldb:hsqldb:1.8.0.10"
+ testRuntime "org.hsqldb:hsqldb:2.2.8"
}
jar {
svn commit: r1304189 - /tapestry/tapestry5/trunk/tapestry-hibernate-core/build.gradle
Author: kaosko
Date: Fri Mar 23 05:05:27 2012
New Revision: 1304189
URL: http://svn.apache.org/viewvc?rev=1304189&view=rev
Log:
Upgrade hibernate dependency to 4.1.1 as discussed on the dev list
(http://markmail.org/thread/3nhpl5cptec4hfgf)
Modified:
tapestry/tapestry5/trunk/tapestry-hibernate-core/build.gradle
Modified: tapestry/tapestry5/trunk/tapestry-hibernate-core/build.gradle
URL:
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-hibernate-core/build.gradle?rev=1304189&r1=1304188&r2=1304189&view=diff
==
--- tapestry/tapestry5/trunk/tapestry-hibernate-core/build.gradle (original)
+++ tapestry/tapestry5/trunk/tapestry-hibernate-core/build.gradle Fri Mar 23
05:05:27 2012
@@ -1,6 +1,6 @@
description = "Basic Hibernate services for Tapestry, useable outside of a
Tapestry web application"
-hibernateVersion = '3.6.0.Final'
+hibernateVersion = '4.1.1.Final'
dependencies {
compile project(':tapestry-ioc')
@@ -8,6 +8,7 @@ dependencies {
compile group: 'org.hibernate', name: 'hibernate-core', version:
hibernateVersion, transitive: false
compile "org.hibernate:hibernate-commons-annotations:3.2.0.Final"
compile "org.hibernate.javax.persistence:hibernate-jpa-2.0-api:1.0.0.Final"
+ compile "org.jboss.logging:jboss-logging:3.1.0.GA"
runtime "geronimo-spec:geronimo-spec-jta:1.0-M1"
runtime "antlr:antlr:2.7.6"
@@ -21,7 +22,7 @@ dependencies {
testCompile "org.testng:testng:$testngVersion", { transitive = false }
- testRuntime "org.hsqldb:hsqldb:1.8.0.10"
+ testRuntime "org.hsqldb:hsqldb:2.2.8"
}
jar {
[CONF] Apache Tapestry > Forms and Validation
Forms and Validation
Page edited by Bob Harner
Comment:
Some wordsmithing and a little more about serialization
Changes (13)
...
h1. Storing Data Between Requests
{float:right|background="">width=40%}
{info:title=New in Tapestry 5.4} Starting in Tapestry 5.4, the default behavior for server-side validation failures is to re-render the page within the same request (rather than emitting a redirect). This removes the need to use a session-persistent field to store the validation tracker when validation failures occur.
{since:5.4} {info}
Note: Starting in Tapestry 5.4, the default behavior for server-side validation failures is to re-render the page within the same request (rather than emitting a redirect). This removes the need to use a persistent field to store the tracker. {since}
{float}
As with other action requests, the result of a form submission is to send a redirect to the client which re-renders the page. The ValidationTracker must be stored [persistently|Persistent Page Data] between requests, or all the validation information will be lost (the default ValidationTracker provided by the Form is persistent).
As with other action requests, the result of a form submission is to send a redirect to the client, which results in a second request (to re-render the page). The ValidationTracker must be [persisted|Persistent Page Data] (generally in the HttpSession) across these two requests in order to prevent the loss of validation information. Fortunately, the default ValidationTracker provided by the Form component is persistent, so you don't normally have to worry about it.
Likewise, the individual fields updated by the components should also be persistent.
However, for the same reason, the individual fields updated by the components should also be persisted across requests, and this is something you *do* need to do yourself -- generally with the @Persist annotation.
For example, a Login page, which collects a user name and a password, might look like:
...
{code}
Because of the the fact that a form submission is _two_ requests (the submission itself, then a re-render of the page), it is necessary to make the value stored in the userName field persist between the two requests. This would be necessary for the password field as well, except that the [PasswordField|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/components/PasswordField.html] component never renders a value.
{float:right|width=40%}
{info}
Note that the onSuccess() method is not public; event handler methods can have any visibility, even private. Package private (that is, no modifier) is the typical use, as it allows the component to be tested, from a test case class in the same package.
{info} {float}
Because a form submission is really _two_ requests: the submission itself (which results in a redirect response), then a second request for the page (which results in a re-rendering of the page), it is necessary to persist the userName field between the two requests, by using the @Persist annotation. This would be necessary for the password field as well, except that the [PasswordField|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/components/PasswordField.html] component never renders a value. {tip} To avoid data loss, fields whose values are stored in the HttpSession (such as userName, above) must be serializable, particularly if you want to be able to cluster your application or preserve sessions across server restarts. {tip}
The Form only emits a "success" event if the there are no prior validation errors. This means it is not necessary to write {{if (form.getHasErrors()) return;}} as the first line of the method.
...
Full Content
Related Articles
Page:
Forms and Validation
Page:
Forms and Form Components FAQ
Page:
Bean Validation
The life's blood of any application is form input; this is the most effective way to gather significant information from the user. Wheth
[jira] [Commented] (TAP5-1880) GZip compression should be disabled if the request is over http 1.0
[ https://issues.apache.org/jira/browse/TAP5-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235826#comment-13235826 ] Paul Stanton commented on TAP5-1880: problem with user agent is that we noticed some requests in this scenario would come through with the wrong value ! another ie issue i'm sure. > GZip compression should be disabled if the request is over http 1.0 > --- > > Key: TAP5-1880 > URL: https://issues.apache.org/jira/browse/TAP5-1880 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.3.2 >Reporter: Paul Stanton >Assignee: Howard M. Lewis Ship > Labels: gzip, ie > > Internet explorer when behind a proxy defaults to using HTTP 1.0 (instead of > HTTP 1.1) and in this scenario, GZIP compression is still applied to the > response and the clients do not interpret the response correctly. > This may either be caused by the client incorrectly setting 'accept-encoding' > or incorrectly reading the 'encoding' headers at either end, however since it > only occurs over http 1.0 it should just be disabled for all http 1.0 > requests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1880) GZip compression should be disabled if the request is over http 1.0
[ https://issues.apache.org/jira/browse/TAP5-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235823#comment-13235823 ] Paul Stanton commented on TAP5-1880: yes agree its an ie issue. i assumed HttpServletRequest.getProtocol() would return HTTP/1.1 or HTTP/1.0 ? I haven't gotten around to trying this. > GZip compression should be disabled if the request is over http 1.0 > --- > > Key: TAP5-1880 > URL: https://issues.apache.org/jira/browse/TAP5-1880 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.3.2 >Reporter: Paul Stanton >Assignee: Howard M. Lewis Ship > Labels: gzip, ie > > Internet explorer when behind a proxy defaults to using HTTP 1.0 (instead of > HTTP 1.1) and in this scenario, GZIP compression is still applied to the > response and the clients do not interpret the response correctly. > This may either be caused by the client incorrectly setting 'accept-encoding' > or incorrectly reading the 'encoding' headers at either end, however since it > only occurs over http 1.0 it should just be disabled for all http 1.0 > requests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1880) GZip compression should be disabled if the request is over http 1.0
[ https://issues.apache.org/jira/browse/TAP5-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235788#comment-13235788 ] Steve Eynon commented on TAP5-1880: --- I've not looked at the HTTP 1.0 RFC yet but this seems to suggest that HTTP 1.0 supports GZIP, which would mean it's (yet another) IE issue...: http://stackoverflow.com/questions/239512/http-1-0-and-deflate-gzip > GZip compression should be disabled if the request is over http 1.0 > --- > > Key: TAP5-1880 > URL: https://issues.apache.org/jira/browse/TAP5-1880 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.3.2 >Reporter: Paul Stanton >Assignee: Howard M. Lewis Ship > Labels: gzip, ie > > Internet explorer when behind a proxy defaults to using HTTP 1.0 (instead of > HTTP 1.1) and in this scenario, GZIP compression is still applied to the > response and the clients do not interpret the response correctly. > This may either be caused by the client incorrectly setting 'accept-encoding' > or incorrectly reading the 'encoding' headers at either end, however since it > only occurs over http 1.0 it should just be disabled for all http 1.0 > requests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1880) GZip compression should be disabled if the request is over http 1.0
[ https://issues.apache.org/jira/browse/TAP5-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235766#comment-13235766 ] Howard M. Lewis Ship commented on TAP5-1880: Not looking good on detecting this via HTTP version ... how about via user agent? What kind of user agent string is coming up through your proxy? > GZip compression should be disabled if the request is over http 1.0 > --- > > Key: TAP5-1880 > URL: https://issues.apache.org/jira/browse/TAP5-1880 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.3.2 >Reporter: Paul Stanton >Assignee: Howard M. Lewis Ship > Labels: gzip, ie > > Internet explorer when behind a proxy defaults to using HTTP 1.0 (instead of > HTTP 1.1) and in this scenario, GZIP compression is still applied to the > response and the clients do not interpret the response correctly. > This may either be caused by the client incorrectly setting 'accept-encoding' > or incorrectly reading the 'encoding' headers at either end, however since it > only occurs over http 1.0 it should just be disabled for all http 1.0 > requests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1880) GZip compression should be disabled if the request is over http 1.0
[ https://issues.apache.org/jira/browse/TAP5-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235756#comment-13235756 ] Howard M. Lewis Ship commented on TAP5-1880: http://stackoverflow.com/questions/9827393/using-servlet-api-how-to-determine-if-request-was-http-1-0-or-http-1-1 > GZip compression should be disabled if the request is over http 1.0 > --- > > Key: TAP5-1880 > URL: https://issues.apache.org/jira/browse/TAP5-1880 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.3.2 >Reporter: Paul Stanton >Assignee: Howard M. Lewis Ship > Labels: gzip, ie > > Internet explorer when behind a proxy defaults to using HTTP 1.0 (instead of > HTTP 1.1) and in this scenario, GZIP compression is still applied to the > response and the clients do not interpret the response correctly. > This may either be caused by the client incorrectly setting 'accept-encoding' > or incorrectly reading the 'encoding' headers at either end, however since it > only occurs over http 1.0 it should just be disabled for all http 1.0 > requests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1880) GZip compression should be disabled if the request is over http 1.0
[ https://issues.apache.org/jira/browse/TAP5-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235743#comment-13235743 ] Howard M. Lewis Ship commented on TAP5-1880: I'm struggling with how to determine if the request is HTTP/1.0 or HTTP/1.1 ... I haven't yet found a Servlet API method for this, or even anywhere it's exposed inside the Jetty code base. > GZip compression should be disabled if the request is over http 1.0 > --- > > Key: TAP5-1880 > URL: https://issues.apache.org/jira/browse/TAP5-1880 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.3.2 >Reporter: Paul Stanton >Assignee: Howard M. Lewis Ship > Labels: gzip, ie > > Internet explorer when behind a proxy defaults to using HTTP 1.0 (instead of > HTTP 1.1) and in this scenario, GZIP compression is still applied to the > response and the clients do not interpret the response correctly. > This may either be caused by the client incorrectly setting 'accept-encoding' > or incorrectly reading the 'encoding' headers at either end, however since it > only occurs over http 1.0 it should just be disabled for all http 1.0 > requests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1880) GZip compression should be disabled if the request is over http 1.0
[ https://issues.apache.org/jira/browse/TAP5-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235711#comment-13235711 ] Howard M. Lewis Ship commented on TAP5-1880: If you haven't already realized this ... you could add a filter to detect this and use Response.disableCompression() as a workaround until a bug fix is available. > GZip compression should be disabled if the request is over http 1.0 > --- > > Key: TAP5-1880 > URL: https://issues.apache.org/jira/browse/TAP5-1880 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.3.2 >Reporter: Paul Stanton >Assignee: Howard M. Lewis Ship > Labels: gzip, ie > > Internet explorer when behind a proxy defaults to using HTTP 1.0 (instead of > HTTP 1.1) and in this scenario, GZIP compression is still applied to the > response and the clients do not interpret the response correctly. > This may either be caused by the client incorrectly setting 'accept-encoding' > or incorrectly reading the 'encoding' headers at either end, however since it > only occurs over http 1.0 it should just be disabled for all http 1.0 > requests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TAP5-1880) gzip compression should be disabled if the request is over http 1.0
[ https://issues.apache.org/jira/browse/TAP5-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Howard M. Lewis Ship reassigned TAP5-1880: -- Assignee: Howard M. Lewis Ship > gzip compression should be disabled if the request is over http 1.0 > --- > > Key: TAP5-1880 > URL: https://issues.apache.org/jira/browse/TAP5-1880 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.3.2 >Reporter: Paul Stanton >Assignee: Howard M. Lewis Ship > Labels: gzip, ie > > Internet explorer when behind a proxy defaults to using HTTP 1.0 (instead of > HTTP 1.1) and in this scenario, GZIP compression is still applied to the > response and the clients do not interpret the response correctly. > This may either be caused by the client incorrectly setting 'accept-encoding' > or incorrectly reading the 'encoding' headers at either end, however since it > only occurs over http 1.0 it should just be disabled for all http 1.0 > requests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1880) GZip compression should be disabled if the request is over http 1.0
[ https://issues.apache.org/jira/browse/TAP5-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Howard M. Lewis Ship updated TAP5-1880: --- Labels: gzip ie (was: gzip) Issue Type: Bug (was: Improvement) Summary: GZip compression should be disabled if the request is over http 1.0 (was: gzip compression should be disabled if the request is over http 1.0) > GZip compression should be disabled if the request is over http 1.0 > --- > > Key: TAP5-1880 > URL: https://issues.apache.org/jira/browse/TAP5-1880 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.3.2 >Reporter: Paul Stanton >Assignee: Howard M. Lewis Ship > Labels: gzip, ie > > Internet explorer when behind a proxy defaults to using HTTP 1.0 (instead of > HTTP 1.1) and in this scenario, GZIP compression is still applied to the > response and the clients do not interpret the response correctly. > This may either be caused by the client incorrectly setting 'accept-encoding' > or incorrectly reading the 'encoding' headers at either end, however since it > only occurs over http 1.0 it should just be disabled for all http 1.0 > requests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
