[jira] Commented: (TAP5-879) 404 is never raised automatically if the application has an index page.
[
https://issues.apache.org/jira/browse/TAP5-879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800159#action_12800159
]
Christophe Cordenier commented on TAP5-879:
---
Hi,
Finally i came up to this solution :
1. Add a component request filter to check activation context parameters
2. i didn't modify the matches method of ComponentEvent class to be less
intrusive
3. i didn't change the behavior at the OnEventWorker because i guess it's too
late for security checking
The algorithm is :
1. If no activation method then no parameter is authorized
2. If activation methods exist then verify that at least that one method
matches with the activation context parameter count and type (this induces type
coercion)
3. If an activation method exists with EventContext, or List or Object[] param
then it is flaged as not secured
Remark : The patch provided contains some code from the OnEventWorker and does
introspection everytime the class is invalidated and then keep metadatas in a
cache.
Aslo ,during test i have seen that this kind of code is not handled by Tapestry
onActivate(Long number) {...}
onActivate(String message) {...}
Calling this page with a string activation context parameter generate a
coercion exception, i guess this was a decision in design.
Best Regards,
Christophe.
404 is never raised automatically if the application has an index page.
---
Key: TAP5-879
URL: https://issues.apache.org/jira/browse/TAP5-879
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Christophe Cordenier
The default behavior of PageRenderDispatcher when a user access to a URL like
'http://localhost/demo/blah' (where 'demo' is the application context and
'blah' is a page that does not exist) is to translate to
'http://localhost/demo/index/blah' if an index page exists even if it has no
activation method.
It could be a better solution to check if a the index page has an activation
method with the corresponding parameter number and type, and automatically
raise a http 404 if not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-879) 404 is never raised automatically if the application has an index page.
[ https://issues.apache.org/jira/browse/TAP5-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Cordenier updated TAP5-879: -- Attachment: TAP5-879.txt 404 is never raised automatically if the application has an index page. --- Key: TAP5-879 URL: https://issues.apache.org/jira/browse/TAP5-879 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Christophe Cordenier Attachments: TAP5-879.txt The default behavior of PageRenderDispatcher when a user access to a URL like 'http://localhost/demo/blah' (where 'demo' is the application context and 'blah' is a page that does not exist) is to translate to 'http://localhost/demo/index/blah' if an index page exists even if it has no activation method. It could be a better solution to check if a the index page has an activation method with the corresponding parameter number and type, and automatically raise a http 404 if not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-869) When Submit is used inside Loop and configured as defered (default), context value from last loop iteration is always taken as selected event argument
[ https://issues.apache.org/jira/browse/TAP5-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800165#action_12800165 ] Torsten Krüger commented on TAP5-869: - When Submit is used inside Grid, context value from last loop iteration is always taken as selected event argument. In contrast to Loop setting defer=false does not solve the issue for Grid. Using eventlink with an encapsulated button instead of submit causes the event to occur twice! When Submit is used inside Loop and configured as defered (default), context value from last loop iteration is always taken as selected event argument Key: TAP5-869 URL: https://issues.apache.org/jira/browse/TAP5-869 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Vjeran Marcinko One of major uses of Submit's context parameter is when Submit is used inside Loop to be able to distinguish which button was pressed. Unfortunately, always context value from last loop iteration gets passed via selected event argument, making it always look as if last iteration submit was selected. When defer parameter is set to false (it's true by default), then everything works fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-876) Arrow icons used by Palette component should be converted to GIFs to look reasonable in IE
[
https://issues.apache.org/jira/browse/TAP5-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800178#action_12800178
]
Richard Cross commented on TAP5-876:
Not sure exactly what you mean, unless you're referring to the way the disabled
arrows are rendered in IE8. The problem is in this part of default.css
DIV.t-palette-controls BUTTON[disabled] IMG {
filter: alpha(opacity = 25);
-moz-opacity: .25;
}
An explanation (and demonstration) can be found here:
http://www.quirksmode.org/css/opacity.html and here:
http://www.itnewb.com/v/Cross-Browser-CSS-Opacity-and-the-JavaScript-Fade-Fading-Effect
In theory, we should change this to:
DIV.t-palette-controls BUTTON[disabled] IMG {
-ms-filter:progid:DXImageTransform.Microsoft.Alpha(Opacity=25);
filter: alpha(opacity = 25);
opacity: .25;
}
Firefox 3.5 no longer supports -moz-opacity, it uses just opacity. In fact,
replacing this setting allows for transparent icons in both Firefox 3.5,
Safari 4 and dozens of other web browsers.
I could not get the -ms-filter part to work, even though a separate test of a
web page using this in the stylesheet (the QuirksMode link above) works for me
in IE8. Is there something else going on under the hood of Tapestry that
prevents this style from being applied?
In the end, the only way I could get rid of ugly arrow icons in IE8 was with:
DIV.t-palette-controls BUTTON[disabled] IMG {
}
Unfortunately, this latter solution is the I'll have to go with in order to get
a commercial product out of the door (deadline is a couple of days' time!), but
maybe someone could look into getting the former solution working?
Arrow icons used by Palette component should be converted to GIFs to look
reasonable in IE
--
Key: TAP5-876
URL: https://issues.apache.org/jira/browse/TAP5-876
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Reporter: Howard M. Lewis Ship
Priority: Minor
Hate to compromise on this (PNG is the way to go) but they just look awful in
IE.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-986) sendError in onActivate / Tapestry error dispatching
sendError in onActivate / Tapestry error dispatching Key: TAP5-986 URL: https://issues.apache.org/jira/browse/TAP5-986 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Christophe Cordenier With this kind of configuration in web.xml : filter-mapping filter-nametapestryFilter/filter-name url-pattern/*/url-pattern dispatcherERROR/dispatcher dispatcherREQUEST/dispatcher /filter-mapping error-page error-code403/error-code location/error/AccessDenied/location /error-page error-page error-code404/error-code location/error/NotFound/location /error-page RestoreDirtySessionObjects is generating a NullPointerException with this line : Session session = request.getSession(false); It seems that the dispatching is done in one single thread, then the initial class to RestoreDirtySessionObjects is delay, and request object is lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-986) sendError in onActivate / Tapestry error dispatching
[ https://issues.apache.org/jira/browse/TAP5-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Cordenier updated TAP5-986: -- Attachment: TAP5-986.txt sendError in onActivate / Tapestry error dispatching Key: TAP5-986 URL: https://issues.apache.org/jira/browse/TAP5-986 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Christophe Cordenier Attachments: TAP5-986.txt With this kind of configuration in web.xml : filter-mapping filter-nametapestryFilter/filter-name url-pattern/*/url-pattern dispatcherERROR/dispatcher dispatcherREQUEST/dispatcher /filter-mapping error-page error-code403/error-code location/error/AccessDenied/location /error-page error-page error-code404/error-code location/error/NotFound/location /error-page RestoreDirtySessionObjects is generating a NullPointerException with this line : Session session = request.getSession(false); It seems that the dispatching is done in one single thread, then the initial class to RestoreDirtySessionObjects is delay, and request object is lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-986) sendError in onActivate / Tapestry error dispatching
[ https://issues.apache.org/jira/browse/TAP5-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800234#action_12800234 ] Christophe Cordenier commented on TAP5-986: --- About the patch : I have implement a ComponentEventResultProcessor that throw an exception when the type return is an instance of HttpError. The sendError call is effectively made in a RequestFilter so the RestoreDirtySessionObjects dirty is bypassed like as RequestErrorFilter does (return true in catch Throwable clause) One advantage of this solution is that it's easy for the developper to send an error without injecting Response service in its page. sendError in onActivate / Tapestry error dispatching Key: TAP5-986 URL: https://issues.apache.org/jira/browse/TAP5-986 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Christophe Cordenier Attachments: TAP5-986.txt With this kind of configuration in web.xml : filter-mapping filter-nametapestryFilter/filter-name url-pattern/*/url-pattern dispatcherERROR/dispatcher dispatcherREQUEST/dispatcher /filter-mapping error-page error-code403/error-code location/error/AccessDenied/location /error-page error-page error-code404/error-code location/error/NotFound/location /error-page RestoreDirtySessionObjects is generating a NullPointerException with this line : Session session = request.getSession(false); It seems that the dispatching is done in one single thread, then the initial class to RestoreDirtySessionObjects is delay, and request object is lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-876) Arrow icons used by Palette component should be converted to GIFs to look reasonable in IE
[ https://issues.apache.org/jira/browse/TAP5-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800245#action_12800245 ] Richard Cross commented on TAP5-876: Worked it out... despite using the correct settings above, IE8 doesn't handle PNG images very well. I converted the PNGs to GIF but, although they look a lot better than the mangle PNGs, they look a lot rougher than the PNG files supplied by tapestry. Arrow icons used by Palette component should be converted to GIFs to look reasonable in IE -- Key: TAP5-876 URL: https://issues.apache.org/jira/browse/TAP5-876 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Reporter: Howard M. Lewis Ship Priority: Minor Hate to compromise on this (PNG is the way to go) but they just look awful in IE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TAP5-876) Arrow icons used by Palette component should be converted to GIFs to look reasonable in IE
[ https://issues.apache.org/jira/browse/TAP5-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800245#action_12800245 ] Richard Cross edited comment on TAP5-876 at 1/14/10 4:37 PM: - Worked it out... despite using the correct settings above, IE8 doesn't handle opacity with transparent PNG files. I converted the PNGs to GIFs but, although they look a lot better than the mangle PNGs, they look a lot rougher than the PNG files supplied by tapestry. was (Author: m0thr4): Worked it out... despite using the correct settings above, IE8 doesn't handle PNG images very well. I converted the PNGs to GIF but, although they look a lot better than the mangle PNGs, they look a lot rougher than the PNG files supplied by tapestry. Arrow icons used by Palette component should be converted to GIFs to look reasonable in IE -- Key: TAP5-876 URL: https://issues.apache.org/jira/browse/TAP5-876 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Reporter: Howard M. Lewis Ship Priority: Minor Hate to compromise on this (PNG is the way to go) but they just look awful in IE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-869) When Submit is used inside Loop and configured as defered (default), context value from last loop iteration is always taken as selected event argument
[ https://issues.apache.org/jira/browse/TAP5-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800411#action_12800411 ] Leonard Lu commented on TAP5-869: - Should other searchers stumble on this ticket, there's a component in the Tapestry5 wiki that works around this issue: http://wiki.apache.org/tapestry/Tapestry5SubmitContextComponent When Submit is used inside Loop and configured as defered (default), context value from last loop iteration is always taken as selected event argument Key: TAP5-869 URL: https://issues.apache.org/jira/browse/TAP5-869 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Vjeran Marcinko One of major uses of Submit's context parameter is when Submit is used inside Loop to be able to distinguish which button was pressed. Unfortunately, always context value from last loop iteration gets passed via selected event argument, making it always look as if last iteration submit was selected. When defer parameter is set to false (it's true by default), then everything works fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
