[jira] [Created] (TAP5-2062) Ajax alerts not rendered after a JS call to dismissOne()
Steve Eynon created TAP5-2062: - Summary: Ajax alerts not rendered after a JS call to dismissOne() Key: TAP5-2062 URL: https://issues.apache.org/jira/browse/TAP5-2062 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Steve Eynon Priority: Minor See http://tapestry.1045711.n5.nabble.com/T5-4-alpha-2-Ajax-alerts-not-rendered-after-a-call-to-dismissAll-td5719668.html There's a typo on Line 77 (ish) of alert.coffee: container.on click button.close, - should actually be: container.on click, button.close, - -- 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-2062) Ajax alerts not rendered after a JS call to dismissOne()
[ https://issues.apache.org/jira/browse/TAP5-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Eynon updated TAP5-2062: -- Attachment: alert.coffee.patch A 2 line fix for alert.coffee Ajax alerts not rendered after a JS call to dismissOne() Key: TAP5-2062 URL: https://issues.apache.org/jira/browse/TAP5-2062 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.4 Reporter: Steve Eynon Priority: Minor Labels: alert Attachments: alert.coffee.patch See http://tapestry.1045711.n5.nabble.com/T5-4-alpha-2-Ajax-alerts-not-rendered-after-a-call-to-dismissAll-td5719668.html There's a typo on Line 77 (ish) of alert.coffee: container.on click button.close, - should actually be: container.on click, button.close, - -- 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] [Commented] (TAP5-1770) PageTester causes StringIndexOutOfBoundsException for any page request path with query parameter
[
https://issues.apache.org/jira/browse/TAP5-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447435#comment-13447435
]
Steve Eynon commented on TAP5-1770:
---
It'd be nice if it was fixed (esp as it's only a 4 character variable name
change!) as currently it's a patch I have to apply to every project.
PageTester causes StringIndexOutOfBoundsException for any page request path
with query parameter
Key: TAP5-1770
URL: https://issues.apache.org/jira/browse/TAP5-1770
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-test
Affects Versions: 5.3
Reporter: Kevin Lin
I was running a web test using the latest source code from testify on a T5.3
application. And I get the following exception for any tests that contains a
request/event:
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1937)
at java.lang.String.substring(String.java:1904)
at
org.apache.tapestry5.test.PageTester.setupRequestFromURI(PageTester.java:345)
at
org.apache.tapestry5.test.PageTester.setupRequestFromLink(PageTester.java:331)
at
org.apache.tapestry5.test.PageTester.runComponentEventRequest(PageTester.java:313)
at
org.apache.tapestry5.test.PageTester.clickLinkAndReturnResponse(PageTester.java:264)
...
At bit digging through the code shows that there is mostly a coding bug in
org.apache.tapestry5.test.PageTester#setupRequestFromURI()
(PageTester.java:345):
private void setupRequestFromURI(String URI)
{
String linkPath = stripContextFromPath(URI);
int comma = linkPath.indexOf('?');
String path = comma 0 ? linkPath : linkPath.substring(0, comma);
request.clear().setPath(path);
if (comma 0)
decodeParametersIntoRequest(path.substring(comma + 1));
}
The path variable is the URL path with the event parameters (?xxx) stripped,
trying to substring it again cause the IndexOutOfBounds exception. The
correct variable to pass should instead be: linkPath. A comparison with the
same class file confirms my findings.
--
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] [Commented] (TAP5-1733) Throw bespoke exceptions so they may be more easily identified by Error Handlers
[
https://issues.apache.org/jira/browse/TAP5-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13444003#comment-13444003
]
Steve Eynon commented on TAP5-1733:
---
Fixes to convert malformed URLs in T5.3.4 into a specific MalformedUrlException
is given here:
How to return HTTP 404 for in-exact URL requests
http://tapestry.1045711.n5.nabble.com/How-to-return-HTTP-404-for-in-exact-URL-requests-td5715875.html
Throw bespoke exceptions so they may be more easily identified by Error
Handlers
Key: TAP5-1733
URL: https://issues.apache.org/jira/browse/TAP5-1733
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.3
Reporter: Steve Eynon
Priority: Minor
Labels: exception-handling
Two exceptions in particular tend to be thrown prolifically by live sites
when they are crawled by robots. They are:
- java.lang.RuntimeException: Forms require that the request method be POST
and that the t:formdata query parameter have values.
- java.lang.IllegalArgumentException: Input string 'XXX' is not valid; the
character 'X' at position X is not valid.
To save needless reporting of benign errors (and to prevent the error logs
from filling up) these exceptions are usually ignored by implementing Error
Handlers. But the ErrorHandler has to currently check the exception message:
if (e.getMessage().contains(Forms require that the request method be POST))
{
doIgnore();
}
which is both brittle and nasty. Instead it'd be great if Tapestry could
throw some bespoke exceptions so the above could be re-written as:
if (e instanceof FormsRequirePostException) {
doIngore();
}
Email thread below:
http://tapestry.1045711.n5.nabble.com/Safari-for-example-browser-history-and-form-exception-td4942074.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] [Commented] (TAP5-841) DateField selects wrong date if client is in a different timezone than the server
[ https://issues.apache.org/jira/browse/TAP5-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411899#comment-13411899 ] Steve Eynon commented on TAP5-841: -- It would actually be nice not to constantly patch this bug. DateField selects wrong date if client is in a different timezone than the server - Key: TAP5-841 URL: https://issues.apache.org/jira/browse/TAP5-841 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: David Rees Assignee: Robert Zeigler Attachments: T5.3-DateField-Patch.txt This affects 5.0.18 and 5.1.0.5 in my testing. Situation is that if the server is running in a different timezone than the client, the DateField chooser will select the wrong date on the calendar. For example, if the server is running in Pacific/Auckland and the client is running in America/Los_Angeles, Auckland is a day ahead of Los Angeles for most of the time and the bug is easy to reproduce. Right now it is 3:40PM Sep 8, 2009 America/Los_Angeles and 10:40AM Sep 9, 2009 Pacific/Auckland. If the date on the server to be displayed by the DateField is Sep 9, 2009, when you select the date chooser, Sep 8, 2009 is selected in the JavaScript calendar dialog. I found this message which seems to indicate that Howard thought it might be an issue - looks like he was correct: http://www.nabble.com/Re%3A-Tapestry-5.0.15-DateField-localization-problem--patch-included--p20033325.html -- 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-1932) Exposing the Link in the EventLink component
[
https://issues.apache.org/jira/browse/TAP5-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Eynon updated TAP5-1932:
--
Attachment: Link.patch
I'm just asking for the link field in AbstractLink to be set *before* it is
written out. That way I can alter it.
The LinkTransformer API is not appropriate in this case for I need to target a
particular link component, not a sweeping set of URLs. A mixin would be perfect
as the intent would be clear and documented in the .tml.
In addition, protected fields are source of problems
Easy, I was just trying to be helpful!
Here, the attached patch uses a setter instead. It's not the prettiest
solution, but one with the least amount of changes (~3 lines). I think the code
around the AbstractLink could be a bit cleaner as a whole, i.e. the way the
link field is set as a by-product of the writeLink() function isn't too clear.
Exposing the Link in the EventLink component
Key: TAP5-1932
URL: https://issues.apache.org/jira/browse/TAP5-1932
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.3.3
Reporter: Steve Eynon
Priority: Trivial
Attachments: Link.patch
I would like to alter the Link in an EventLink via a Mixin - specifically,
remove the LoopBack parameter.
To do this, the AbstractLink.link field needs to be set *before* the link
is rendered and a simple change to
org.apache.tapestry5.corelib.base.AbstractComponentEventLink would accomplish
this:
protected void setupRender() {
super.link = createLink(context);
}
AbstractLink.link would also need to become protected.
I believe the above to be a small yet useful enhancement to the Link
Component API.
--
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] [Comment Edited] (TAP5-1936) REOPEN TAP5-698 - PageTester's setupRequestFromURI incorrectly uses substring twice on same string
[ https://issues.apache.org/jira/browse/TAP5-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13396640#comment-13396640 ] Steve Eynon edited comment on TAP5-1936 at 6/19/12 10:08 AM: - This is a duplicate of TAP5-1770 - Thanks for the patch file though! was (Author: slimerdude): This is a duplicate of TAP5-1770 - https://issues.apache.org/jira/browse/TAP5-1770 Thanks for the patch file though! REOPEN TAP5-698 - PageTester's setupRequestFromURI incorrectly uses substring twice on same string -- Key: TAP5-1936 URL: https://issues.apache.org/jira/browse/TAP5-1936 Project: Tapestry 5 Issue Type: Bug Components: tapestry-test Affects Versions: 5.3.3 Reporter: Denis Delangle Assignee: Howard M. Lewis Ship Attachments: patch-TAP5-1936.txt I get this error when clicking a link with parameters in PageTester java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1937) at java.lang.String.substring(String.java:1904) at org.apache.tapestry5.test.PageTester.setupRequestFromURI(PageTester.java:345) That bug was corrected revision 896555 and put back revision 1185926. The correction is trivial but have been done twice, so the bug is still there. I submit a patch to correct it -- 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-1936) REOPEN TAP5-698 - PageTester's setupRequestFromURI incorrectly uses substring twice on same string
[ https://issues.apache.org/jira/browse/TAP5-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13396640#comment-13396640 ] Steve Eynon commented on TAP5-1936: --- This is a duplicate of TAP5-1770 - https://issues.apache.org/jira/browse/TAP5-1770 Thanks for the patch file though! REOPEN TAP5-698 - PageTester's setupRequestFromURI incorrectly uses substring twice on same string -- Key: TAP5-1936 URL: https://issues.apache.org/jira/browse/TAP5-1936 Project: Tapestry 5 Issue Type: Bug Components: tapestry-test Affects Versions: 5.3.3 Reporter: Denis Delangle Assignee: Howard M. Lewis Ship Attachments: patch-TAP5-1936.txt I get this error when clicking a link with parameters in PageTester java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1937) at java.lang.String.substring(String.java:1904) at org.apache.tapestry5.test.PageTester.setupRequestFromURI(PageTester.java:345) That bug was corrected revision 896555 and put back revision 1185926. The correction is trivial but have been done twice, so the bug is still there. I submit a patch to correct it -- 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-1914) Alerts needs a parameter to show/hide Dismiss all
Steve Eynon
commented on TAP5-1914
Alerts needs a parameter to show/hide Dismiss all
I stick this in my CSS:
/* remove the Dismiss All link */
#alerts .t-alert-controls {
display: none;
}
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-1931) Alerts can not be dismissed in IE8.
Steve Eynon created TAP5-1931:
-
Summary: Alerts can not be dismissed in IE8.
Key: TAP5-1931
URL: https://issues.apache.org/jira/browse/TAP5-1931
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.3.3
Reporter: Steve Eynon
Priority: Minor
IE woes; alerts can not be dismissed in IE8 (HTML5 DocType, non-compatibility
mode). Although the delete icon (the t-dismiss DIV) is rendered in the correct
place on the screen, it does not respond to mouse clicks and the mouse pointer
does not change to pointer.
It seems the problem occurs because the dismiss is floated. Removing the float
in favour of right positioning enables the dismiss to be clicked again.
The following CSS changes solve the issue.
/* The dismiss button on IE can't be clicked if it's floated!??? */
DIV.t-dismiss {
float:none;
}
/* compensate for non-floating */
DIV.t-alert-container {
position: relative;
}
DIV.t-dismiss {
position: absolute;
top: 1px;
right:2px;
}
--
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] [Created] (TAP5-1932) Exposing the Link in the EventLink component
Steve Eynon created TAP5-1932:
-
Summary: Exposing the Link in the EventLink component
Key: TAP5-1932
URL: https://issues.apache.org/jira/browse/TAP5-1932
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.3.3
Reporter: Steve Eynon
Priority: Trivial
I would like to alter the Link in an EventLink via a Mixin - specifically,
remove the LoopBack parameter.
To do this, the AbstractLink.link field needs to be set *before* the link is
rendered and a simple change to
org.apache.tapestry5.corelib.base.AbstractComponentEventLink would accomplish
this:
protected void setupRender() {
super.link = createLink(context);
}
AbstractLink.link would also need to become protected.
I believe the above to be a small yet useful enhancement to the Link Component
API.
--
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-841) DateField selects wrong date if client is in a different timezone than the server
[
https://issues.apache.org/jira/browse/TAP5-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107856#comment-13107856
]
Steve Eynon commented on TAP5-841:
--
the patch you provided doesn't support IE 9
Hmm... we tested it on IE8 with and with out compatibility mode to IE7, what
makes you say it's only for IE9 and above? ('cos if it's true we need to fix
it!)
I'm also aware of the test, um, lackage (hence my bracketed comment), but as
you say - it's a tricky one. I would like to say I have some ideas, but I've
not yet looked into how T5 performs its JS testing.
DateField selects wrong date if client is in a different timezone than the
server
-
Key: TAP5-841
URL: https://issues.apache.org/jira/browse/TAP5-841
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: David Rees
Assignee: Robert Zeigler
Attachments: T5.3-DateField-Patch.txt
This affects 5.0.18 and 5.1.0.5 in my testing.
Situation is that if the server is running in a different timezone than the
client, the DateField chooser will select the wrong date on the calendar.
For example, if the server is running in Pacific/Auckland and the client is
running in America/Los_Angeles, Auckland is a day ahead of Los Angeles
for most of the time and the bug is easy to reproduce.
Right now it is 3:40PM Sep 8, 2009 America/Los_Angeles and 10:40AM Sep 9,
2009 Pacific/Auckland. If the date on the server to be displayed by the
DateField is Sep 9, 2009, when you select the date chooser, Sep 8, 2009 is
selected in the JavaScript calendar dialog.
I found this message which seems to indicate that Howard thought it might be
an issue - looks like he was correct:
http://www.nabble.com/Re%3A-Tapestry-5.0.15-DateField-localization-problem--patch-included--p20033325.html
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (TAP5-841) DateField selects wrong date if client is in a different timezone than the server
[ https://issues.apache.org/jira/browse/TAP5-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107138#comment-13107138 ] Steve Eynon edited comment on TAP5-841 at 9/18/11 12:48 PM: I've attached a patch for T5.3, but I dare say it also works for T5.2.6. It looks bad that T5 still doesn't have a working Date component. As a fix for this is only a couple of lines I'm very surprised this JIRA is still out standing! (Oh, and before it's mentioned, no there are no unit tests in the patch - trying to get a working dev env for Tapestry was taking too much time. Therefore the patch is just intended for users to Munky Patch their T5 jar.) was (Author: slimerdude): I've attached a patch for T5.3, but given this JIRA has not been touched for 2 years I dare say it also works for T5.2.6. As a fix for this is only a couple of lines it looks bad that T5 still doesn't have a working Date component. I've never deployed to a prod server in the same country / time zone as the users so I can't believe this issue is still out standing! (Before it's mentioned, no there are no unit tests in the patch - trying to get a working dev env for Tapestry was taking too much time. Therefore the patch is just intended for users to Munky Patch their T5 jar.) DateField selects wrong date if client is in a different timezone than the server - Key: TAP5-841 URL: https://issues.apache.org/jira/browse/TAP5-841 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: David Rees Assignee: Robert Zeigler Attachments: T5.3-DateField-Patch.txt This affects 5.0.18 and 5.1.0.5 in my testing. Situation is that if the server is running in a different timezone than the client, the DateField chooser will select the wrong date on the calendar. For example, if the server is running in Pacific/Auckland and the client is running in America/Los_Angeles, Auckland is a day ahead of Los Angeles for most of the time and the bug is easy to reproduce. Right now it is 3:40PM Sep 8, 2009 America/Los_Angeles and 10:40AM Sep 9, 2009 Pacific/Auckland. If the date on the server to be displayed by the DateField is Sep 9, 2009, when you select the date chooser, Sep 8, 2009 is selected in the JavaScript calendar dialog. I found this message which seems to indicate that Howard thought it might be an issue - looks like he was correct: http://www.nabble.com/Re%3A-Tapestry-5.0.15-DateField-localization-problem--patch-included--p20033325.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-841) DateField selects wrong date if client is in a different timezone than the server
[ https://issues.apache.org/jira/browse/TAP5-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Eynon updated TAP5-841: - Attachment: T5.3-DateField-Patch.txt A patch for T5.3 that works as per Paul Stanton's explanation of using a formatted String of -MM-dd for client / server transportation. DateField selects wrong date if client is in a different timezone than the server - Key: TAP5-841 URL: https://issues.apache.org/jira/browse/TAP5-841 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: David Rees Assignee: Robert Zeigler Attachments: T5.3-DateField-Patch.txt This affects 5.0.18 and 5.1.0.5 in my testing. Situation is that if the server is running in a different timezone than the client, the DateField chooser will select the wrong date on the calendar. For example, if the server is running in Pacific/Auckland and the client is running in America/Los_Angeles, Auckland is a day ahead of Los Angeles for most of the time and the bug is easy to reproduce. Right now it is 3:40PM Sep 8, 2009 America/Los_Angeles and 10:40AM Sep 9, 2009 Pacific/Auckland. If the date on the server to be displayed by the DateField is Sep 9, 2009, when you select the date chooser, Sep 8, 2009 is selected in the JavaScript calendar dialog. I found this message which seems to indicate that Howard thought it might be an issue - looks like he was correct: http://www.nabble.com/Re%3A-Tapestry-5.0.15-DateField-localization-problem--patch-included--p20033325.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-841) DateField selects wrong date if client is in a different timezone than the server
[ https://issues.apache.org/jira/browse/TAP5-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107138#comment-13107138 ] Steve Eynon commented on TAP5-841: -- I've attached a patch for T5.3, but given this JIRA has not been touched for 2 years I dare say it also works for T5.2.6. As a fix for this is only a couple of lines it looks bad that T5 still doesn't have a working Date component. I've never deployed to a prod server in the same country / time zone as the users so I can't believe this issue is still out standing! (Before it's mentioned, no there are no unit tests in the patch - trying to get a working dev env for Tapestry was taking too much time. Therefore the patch is just intended for users to Munky Patch their T5 jar.) DateField selects wrong date if client is in a different timezone than the server - Key: TAP5-841 URL: https://issues.apache.org/jira/browse/TAP5-841 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: David Rees Assignee: Robert Zeigler Attachments: T5.3-DateField-Patch.txt This affects 5.0.18 and 5.1.0.5 in my testing. Situation is that if the server is running in a different timezone than the client, the DateField chooser will select the wrong date on the calendar. For example, if the server is running in Pacific/Auckland and the client is running in America/Los_Angeles, Auckland is a day ahead of Los Angeles for most of the time and the bug is easy to reproduce. Right now it is 3:40PM Sep 8, 2009 America/Los_Angeles and 10:40AM Sep 9, 2009 Pacific/Auckland. If the date on the server to be displayed by the DateField is Sep 9, 2009, when you select the date chooser, Sep 8, 2009 is selected in the JavaScript calendar dialog. I found this message which seems to indicate that Howard thought it might be an issue - looks like he was correct: http://www.nabble.com/Re%3A-Tapestry-5.0.15-DateField-localization-problem--patch-included--p20033325.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1628) Have Submit documentation explicitly state when the disabled attribute is evaluated
[ https://issues.apache.org/jira/browse/TAP5-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100122#comment-13100122 ] Steve Eynon commented on TAP5-1628: --- It is less to do with the @Persist annotation and more to do with not knowing the disabled parameter is used / re-evaluated during the server-side form submit event. Once the input element has rendered, it is not obvious the disabled parameter will ever be used / re-evaluated again, for I would expect it's sole purpose is to only render the HTML disabled attribute. I guess I should (have) really ask(ed) why the disabled parameter is evaluated again on form submission, for this not effectively prevent you from re-enabling the component (via javascript) on the web page? Have Submit documentation explicitly state when the disabled attribute is evaluated --- Key: TAP5-1628 URL: https://issues.apache.org/jira/browse/TAP5-1628 Project: Tapestry 5 Issue Type: Improvement Components: documentation Affects Versions: 5.3 Reporter: Steve Eynon Assignee: Bob Harner Priority: Trivial Labels: submit Fix For: 5.3 The disabled attribute for a Submit button is currently loosely documented as : ... Further, a disabled field ignores any value in the request when the form is submitted. http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/corelib/components/Submit.html I would like it to be more explicit, along the lines of: ... Further, if bound, the disabled attribute is re-evaluated upon form submission and the selected event is only fired should it evaluate to 'false'. For this stumped us in work today for a good half hour - it was because we weren't @Persist'ing our disabled attribute. Our expression was t:disabled=!myObject and of course 'myObject' because null / false on form submission. As our submit button was enabled and the form submitted, we saw no reason for the event not to fire. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1628) Have Submit documentation explicitly state when the disabled attribute is evaluated
[ https://issues.apache.org/jira/browse/TAP5-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100129#comment-13100129 ] Steve Eynon commented on TAP5-1628: --- Um, I mean, ...for does this not effectively... Have Submit documentation explicitly state when the disabled attribute is evaluated --- Key: TAP5-1628 URL: https://issues.apache.org/jira/browse/TAP5-1628 Project: Tapestry 5 Issue Type: Improvement Components: documentation Affects Versions: 5.3 Reporter: Steve Eynon Assignee: Bob Harner Priority: Trivial Labels: submit Fix For: 5.3 The disabled attribute for a Submit button is currently loosely documented as : ... Further, a disabled field ignores any value in the request when the form is submitted. http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/corelib/components/Submit.html I would like it to be more explicit, along the lines of: ... Further, if bound, the disabled attribute is re-evaluated upon form submission and the selected event is only fired should it evaluate to 'false'. For this stumped us in work today for a good half hour - it was because we weren't @Persist'ing our disabled attribute. Our expression was t:disabled=!myObject and of course 'myObject' because null / false on form submission. As our submit button was enabled and the form submitted, we saw no reason for the event not to fire. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TAP5-1628) Have Submit documentation explicitly state when the disabled attribute is evaluated
Have Submit documentation explicitly state when the disabled attribute is evaluated --- Key: TAP5-1628 URL: https://issues.apache.org/jira/browse/TAP5-1628 Project: Tapestry 5 Issue Type: Improvement Components: documentation Affects Versions: 5.3 Reporter: Steve Eynon Priority: Trivial The disabled attribute for a Submit button is currently loosely documented as : ... Further, a disabled field ignores any value in the request when the form is submitted. http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/corelib/components/Submit.html I would like it to be more explicit, along the lines of: ... Further, if bound, the disabled attribute is re-evaluated upon form submission and the selected event is only fired should it evaluate to 'false'. For this stumped us in work today for a good half hour - it was because we weren't @Persist'ing our disabled attribute. Our expression was t:disabled=!myObject and of course 'myObject' because null / false on form submission. As our submit button was enabled and the form submitted, we saw no reason for the event not to fire. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1628) Have Submit documentation explicitly state when the disabled attribute is evaluated
[ https://issues.apache.org/jira/browse/TAP5-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Eynon updated TAP5-1628: -- Description: The disabled attribute for a Submit button is currently loosely documented as : ... Further, a disabled field ignores any value in the request when the form is submitted. http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/corelib/components/Submit.html I would like it to be more explicit, along the lines of: ... Further, if bound, the disabled attribute is re-evaluated upon form submission and the selected event is only fired should it evaluate to 'false'. For this stumped us in work today for a good half hour - it was because we weren't @Persist'ing our disabled attribute. Our expression was t:disabled=!myObject and of course 'myObject' because null / false on form submission. As our submit button was enabled and the form submitted, we saw no reason for the event not to fire. was: The disabled attribute for a Submit button is currently loosely documented as : ... Further, a disabled field ignores any value in the request when the form is submitted. http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/corelib/components/Submit.html I would like it to be more explicit, along the lines of: ... Further, if bound, the disabled attribute is re-evaluated upon form submission and the selected event is only fired should it evaluate to 'false'. For this stumped us in work today for a good half hour - it was because we weren't @Persist'ing our disabled attribute. Our expression was t:disabled=!myObject and of course 'myObject' because null / false on form submission. As our submit button was enabled and the form submitted, we saw no reason for the event not to fire. Have Submit documentation explicitly state when the disabled attribute is evaluated --- Key: TAP5-1628 URL: https://issues.apache.org/jira/browse/TAP5-1628 Project: Tapestry 5 Issue Type: Improvement Components: documentation Affects Versions: 5.3 Reporter: Steve Eynon Priority: Trivial Labels: submit The disabled attribute for a Submit button is currently loosely documented as : ... Further, a disabled field ignores any value in the request when the form is submitted. http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/corelib/components/Submit.html I would like it to be more explicit, along the lines of: ... Further, if bound, the disabled attribute is re-evaluated upon form submission and the selected event is only fired should it evaluate to 'false'. For this stumped us in work today for a good half hour - it was because we weren't @Persist'ing our disabled attribute. Our expression was t:disabled=!myObject and of course 'myObject' because null / false on form submission. As our submit button was enabled and the form submitted, we saw no reason for the event not to fire. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TAP5-683) The Tapestry javascript object does not have an INFO logging method to BlackBird
The Tapestry javascript object does not have an INFO logging method to BlackBird Key: TAP5-683 URL: https://issues.apache.org/jira/browse/TAP5-683 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.4, 5.1.0.3, 5.1.0.2 Reporter: Steve Eynon Priority: Trivial The Tapestry javascript object has logging methods for debug, warn and error levels but none for info. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
