[jira] Created: (TAP5-997) Change URL for ioko-tapestry-commons
Change URL for ioko-tapestry-commons Key: TAP5-997 URL: https://issues.apache.org/jira/browse/TAP5-997 Project: Tapestry 5 Issue Type: New Feature Components: documentation Affects Versions: 5.0.19 Reporter: Ben Gidley Hi, Can you change the URL for ioko-tapestry-commons to http://tapestry.ioko.com/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-874) Add t:secure to Form component
[ https://issues.apache.org/jira/browse/TAP5-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762109#action_12762109 ] Ben Gidley commented on TAP5-874: - Although this is a nice feature it is a security risk. A man in the middle could change the posting path for the login form to their own site and harvest usernames/passwords. This doesn't mean it shouldn't be implemented but if it is the docs should warn about this risk. A site requiring strong security (e.g. banking/payments) shouldn't use this pattern. Add t:secure to Form component -- Key: TAP5-874 URL: https://issues.apache.org/jira/browse/TAP5-874 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Olle Hallin Priority: Minor It would be nice if one could make a t:form post to SSL by specifying t:secure=true on the form component. It is a quite common design pattern nowadays to have a login form on each page. It is mostly not necessary however to access all pages via https. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-840) Support character references in tml files with HTML 5 Doctype
[ https://issues.apache.org/jira/browse/TAP5-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12752412#action_12752412 ] Ben Gidley commented on TAP5-840: - It does effect 5.1. Not sure about Trunk but I see no reason why it wouldn't. Support character references in tml files with HTML 5 Doctype - Key: TAP5-840 URL: https://issues.apache.org/jira/browse/TAP5-840 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.0.18 Reporter: Ben Gidley Currently to support HTML character references (e.g. copy;) you need to put a HTML Doctype at the top of the TML file. e.g. !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; However for HTML 5 they have stopped using XML doctypes and instead use !DOCTYPE html If you change tapestry page to use this you can no longer use entities as the XML parser doesn't know what to do. Ideally there should be some kind of logic that detects !DOCTYPE html and include a suitable DTD to resolve the common HTML entities. The HTML 5 specification defines the allowed named character references - http://dev.w3.org/html5/spec/Overview.html#named-character-references. There doesn't seem to be a DTD of allowed references maintained anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-840) Support character references in tml files with HTML 5 Doctype
Support character references in tml files with HTML 5 Doctype - Key: TAP5-840 URL: https://issues.apache.org/jira/browse/TAP5-840 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.0.18 Reporter: Ben Gidley Currently to support HTML character references (e.g. copy;) you need to put a HTML Doctype at the top of the TML file. e.g. !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; However for HTML 5 they have stopped using XML doctypes and instead use !DOCTYPE html If you change tapestry page to use this you can no longer use entities as the XML parser doesn't know what to do. Ideally there should be some kind of logic that detects !DOCTYPE html and include a suitable DTD to resolve the common HTML entities. The HTML 5 specification defines the allowed named character references - http://dev.w3.org/html5/spec/Overview.html#named-character-references. There doesn't seem to be a DTD of allowed references maintained anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-817) When sending muliple page requests very fast (using browser refresh button or pressing a link), for the first time a page is loaded, cause Tapestry to crash and become unr
[ https://issues.apache.org/jira/browse/TAP5-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12745153#action_12745153 ] Ben Gidley commented on TAP5-817: - What setting have you set regarding page pool sizes and production mode? When sending muliple page requests very fast (using browser refresh button or pressing a link), for the first time a page is loaded, cause Tapestry to crash and become unresponsive. - Key: TAP5-817 URL: https://issues.apache.org/jira/browse/TAP5-817 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Mario Luis Gomes Cavalcanti Priority: Blocker When sending muliple page requests very fast (using browser refresh button or pressing a link), for the first time a page is loaded, cause Tapestry to crash and become unresponsive. Steps to reproduce: 1: Have a very simple page containing just some text or a slow loading page to make it easier to reproduce. 2: Restart the web server so there are no pages in the memory. 3: Send multiple requests for the page, very fast using the refresh button or pressing a link multiple times. Result = Tapestry never returns the page and becomes unresponsive. The bug is happening to all the pages on my website, but only if the page has not been previoulsy loaded, e.q, the page is not already in memory. For simple fast loading pages, you have to press the link/refresh button very fast and many, many times. For slower loading pages it is easier to reproduce the bug. I am running tapestry 5.10.5 on a Sun Web Server 7 on Windows XP. This is a very serious bug!!! I cant go to production with this bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-769) JavaScript aggregation can be inefficient across multiple pages with different JS requirements
[ https://issues.apache.org/jira/browse/TAP5-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Gidley updated TAP5-769: Attachment: 0004-TAP-769.patch 0003-TAP-769.patch 0002-TAP-769.patch Here is a patch that implements a solution for this. This changes the DocumentLinker and RenderSupportImpl so that scripts can be 'grouped' prior to assembly into a single script. The default behaviour now is to create one 'group' from the ClientInfrastructure stack and a second group from everything else. This should address a good percentage of this problem raised in this issue. Further enhancements that could be made * Add method to render support to users to create their own groups * Add a contribution point (similar to that provided by http://tapestry.formos.com/projects/ioko-tapestry-commons/tapestry-javascript/) could be provided to allow inclusion of stacks on certain pages * A further contribution to allow replacement for a stack rolled up javascript with a 'production' one e.g. from a CDN. This patch does not address this issue of the length of the filename for the 'stack'. I can't see an easy, generic and cluster safe way to implement that (except via the contribution mentioned above) JavaScript aggregation can be inefficient across multiple pages with different JS requirements -- Key: TAP5-769 URL: https://issues.apache.org/jira/browse/TAP5-769 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Andy Blower Attachments: 0002-TAP-769.patch, 0003-TAP-769.patch, 0004-TAP-769.patch I think Tapestry's JavaScript combination functionality is flawed. Each page component specifies which JS files it needs, which means that JS can be split into functional units (good for development maintenance) and only the JS that's actually needed for that page is added for the client to download. The consequence of this is that pages can have lots of JS files to download, all of which has to be downloaded before the page is loaded/rendered now that the script link tags are enforced to be back in the head section. Our search results page has 34 JS files for instance. Yahoo's YSlow tool recommends that these files are combined and minified, and Tapestry includes functionality to do the first (minifying is on the TODO list I believe) probably as a response to this recommendation which is good. Unfortunately the implementation based on only having the JS files required for a page means that the combined JS can easily be unique for most pages of a site. This means that the client browser has to download cache lots of large JS multiple times (prototype, scriptaculous, tapestry etc) as part of bigger combined files, which I think is probably worse than requesting them separately, but only downloading stuff once and using that for all pages. To solve this issue, Tapestry script combination could combine all of the scripts needed for the site, and not just the unique set for each page. That way only a single JS file needs to be downloaded and cached by the client browser. I'm aware that this may not be that easy given the existing way only scripts needed for the page are put on it, so an alternative solution that may be easier to implement would be to combine scripts into two files for each page. The first file would contain all of the commonly Tapestry provided JS such as prototype.js, scriptaculous.js, effects.js, tapestry.js, etc in one file that's the same for every page, and have the rest in a second file that is unique for the page but that is not likely to include very large JS files, just many little ones. A second flaw that the combination has is that if an external JS file is requested, script combination is aborted rather than just excluding the external file from the combination. One other thing that surprised me about Tapestry's script combination is the length of the generated filename, for example it's 919 characters long for a page on our site. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-769) Combination of JavaScript is flawed
[ https://issues.apache.org/jira/browse/TAP5-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12729241#action_12729241 ] Ben Gidley commented on TAP5-769: - I agree with this problem but regarding the solution - I think if you are that concerned you have to put it into the common JS loaded on each page. (There is an service for this - clientInfrastructure). I have built a library to help with this in ioko-tapestry-commons. The solution you advocate would be ideal - but I can't see any way of achieving it. Combination of JavaScript is flawed --- Key: TAP5-769 URL: https://issues.apache.org/jira/browse/TAP5-769 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Andy Blower I think Tapestry's JavaScript combination functionality is flawed. Each page component specifies which JS files it needs, which means that JS can be split into functional units (good for development maintenance) and only the JS that's actually needed for that page is added for the client to download. The consequence of this is that pages can have lots of JS files to download, all of which has to be downloaded before the page is loaded/rendered now that the script link tags are enforced to be back in the head section. Our search results page has 34 JS files for instance. Yahoo's YSlow tool recommends that these files are combined and minified, and Tapestry includes functionality to do the first (minifying is on the TODO list I believe) probably as a response to this recommendation which is good. Unfortunately the implementation based on only having the JS files required for a page means that the combined JS can easily be unique for most pages of a site. This means that the client browser has to download cache lots of large JS multiple times (prototype, scriptaculous, tapestry etc) as part of bigger combined files, which I think is probably worse than requesting them separately, but only downloading stuff once and using that for all pages. To solve this issue, Tapestry script combination could combine all of the scripts needed for the site, and not just the unique set for each page. That way only a single JS file needs to be downloaded and cached by the client browser. I'm aware that this may not be that easy given the existing way only scripts needed for the page are put on it, so an alternative solution that may be easier to implement would be to combine scripts into two files for each page. The first file would contain all of the commonly Tapestry provided JS such as prototype.js, scriptaculous.js, effects.js, tapestry.js, etc in one file that's the same for every page, and have the rest in a second file that is unique for the page but that is not likely to include very large JS files, just many little ones. A second flaw that the combination has is that if an external JS file is requested, script combination is aborted rather than just excluding the external file from the combination. One other thing that surprised me about Tapestry's script combination is the length of the generated filename, for example it's 919 characters long for a page on our site. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-756) Can you add ioko-tapestry-commons to the related projects list
Can you add ioko-tapestry-commons to the related projects list -- Key: TAP5-756 URL: https://issues.apache.org/jira/browse/TAP5-756 Project: Tapestry 5 Issue Type: New Feature Components: documentation Reporter: Ben Gidley Can you add ioko-tapestry-commons to the related projects list - http://tapestry.formos.com/projects/ioko-tapestry-commons/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-750) Swf files as assets don't play in firefox due to being gziped
Swf files as assets don't play in firefox due to being gziped - Key: TAP5-750 URL: https://issues.apache.org/jira/browse/TAP5-750 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Ben Gidley If you put a swf file as an asset on a page and then try and play that swf it won't play in firefox (other browsers IE, Opera, Safari are ok). The precise symptoms are * The SWF looks like it loads - but you just get the background colour and the main movie doesn't play * If you right click on it you will get the flashright click menu * If you right click and choose play it does play If you move the movie to an near identical path (e.g. bsset/x/xxx.swf) it will play fine. Looking in wireshark the only difference is tapestry GZIP's the swf served as an asset this then stops firefox playing the movie. If you turn GZIP off in tapestry the SWF plays again. Ideally tapestry should let you turn gzip on/off by mime type as well as globally. This would let you enable it for HTML, JS but not for binary objects where it is just a waste of CPU time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-750) Swf files as assets don't play in firefox due to being gziped
[ https://issues.apache.org/jira/browse/TAP5-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12718850#action_12718850 ] Ben Gidley commented on TAP5-750: - A project that demostrates this will (hopefully) shortly be uploaded to tapestry.formos.com - as it includes a swf loader with a test case. Swf files as assets don't play in firefox due to being gziped - Key: TAP5-750 URL: https://issues.apache.org/jira/browse/TAP5-750 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Ben Gidley If you put a swf file as an asset on a page and then try and play that swf it won't play in firefox (other browsers IE, Opera, Safari are ok). The precise symptoms are * The SWF looks like it loads - but you just get the background colour and the main movie doesn't play * If you right click on it you will get the flashright click menu * If you right click and choose play it does play If you move the movie to an near identical path (e.g. bsset/x/xxx.swf) it will play fine. Looking in wireshark the only difference is tapestry GZIP's the swf served as an asset this then stops firefox playing the movie. If you turn GZIP off in tapestry the SWF plays again. Ideally tapestry should let you turn gzip on/off by mime type as well as globally. This would let you enable it for HTML, JS but not for binary objects where it is just a waste of CPU time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-734) Tapestry tutorial documentation refers to old archtype command
Tapestry tutorial documentation refers to old archtype command -- Key: TAP5-734 URL: https://issues.apache.org/jira/browse/TAP5-734 Project: Tapestry 5 Issue Type: Bug Components: documentation Affects Versions: 5.1.0.5, 5.2 Reporter: Ben Gidley The tapestry tutorial build instructions refer to the old archtype command -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-734) Tapestry tutorial documentation refers to old archtype command
[ https://issues.apache.org/jira/browse/TAP5-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Gidley updated TAP5-734: Attachment: 0001-Fixed-archetype-line.patch Here is a corrected version of the file Tapestry tutorial documentation refers to old archtype command -- Key: TAP5-734 URL: https://issues.apache.org/jira/browse/TAP5-734 Project: Tapestry 5 Issue Type: Bug Components: documentation Affects Versions: 5.2, 5.1.0.5 Reporter: Ben Gidley Attachments: 0001-Fixed-archetype-line.patch The tapestry tutorial build instructions refer to the old archtype command -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
