[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-tabpanel&focusedCommentId=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.
[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-tabpanel&focusedCommentId=12800390#action_12800390
]
Christophe Cordenier commented on TAP5-986:
---
After more test i have seen that my sendError request bypass default
ErrorRequestFilter by catching throwable, new code is :
RequestFilter sendErrorFilter = new RequestFilter() {
public boolean service(Request request, Response
response, RequestHandler handler) throws IOException {
try {
return handler.service(request,
response);
} catch (HttpErrorException htex) {
response.sendError(htex.getHttpError().getStatus(),
htex.getHttpError().getMessage());
return true;
}
}
};
> 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 :
>
> tapestryFilter
> /*
> ERROR
> REQUEST
>
>
> 403
> /error/AccessDenied
>
>
> 404
> /error/NotFound
>
> 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] 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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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 : > > tapestryFilter > /* > ERROR > REQUEST > > > 403 > /error/AccessDenied > > > 404 > /error/NotFound > > 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-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-986.txt New patch considering TAP5-986 > 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, TAP5-986.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] 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 : > > tapestryFilter > /* > ERROR > REQUEST > > > 403 > /error/AccessDenied > > > 404 > /error/NotFound > > 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] 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 : tapestryFilter /* ERROR REQUEST 403 /error/AccessDenied 404 /error/NotFound 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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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] 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-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-tabpanel&focusedCommentId=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.
