[jira] Commented: (TAP5-713) Change template parser to not use STAX, as it is not (yet) compatible with Google App Engine
[ https://issues.apache.org/jira/browse/TAP5-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729533#action_12729533 ] Robert Zeigler commented on TAP5-713: - Sadly, using a "provided" dependency is practically impossible since there's no reliable, implementation-independent manner to get at the DTD, as you well know. > Change template parser to not use STAX, as it is not (yet) compatible with > Google App Engine > > > Key: TAP5-713 > URL: https://issues.apache.org/jira/browse/TAP5-713 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.1.0.5 >Reporter: Howard M. Lewis Ship > > The StAX APIs are not on the GAE "white list". > Should be reasonable ot change the code, by using a SAX parser that parses > the template into a list of tokens, and then iterate down the token list as > we do today using StAX. End result will be fewer dependencies to boot. -- 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-713) Change template parser to not use STAX, as it is not (yet) compatible with Google App Engine
[ https://issues.apache.org/jira/browse/TAP5-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729518#action_12729518 ] Tatu Saloranta edited comment on TAP5-713 at 7/9/09 9:57 PM: - Woodstox does not use FactoryFinder for anything. Only thing that does is the Stax API itself. Nothing to do with Woodstox; same would apply to JDK6-bundled Stax implementation (Sun Sjsxp). Ditto for OSGi: Stax/SAX/JAXP all use introspection mechanism that does not work well with OSGi. This is the same for all implementations. One thought regarding nature of dependency: maybe it'd be good to make stax implementation a "provided" dependency: provided by platform or added by users. That way it could use whichever implementation user chose; either the best, or one that container or JDK provides. And finally -- if and when there are concerns about Woodstox, would it kill you to maybe quickly contact Woodstox project team? Who knows, that could even help resolve issues. It is rather frustrating to find that there's enough time to complain, and hack around things, but apparently not enough time to collaborate. Most open source packages have competent and friendly maintainers, who can be concated to help resolve issues (or point out that issues are elsewhere as the case may be); or at least would be interested in learning of such issues. was (Author: cowtowncoder): Huh? Woodstox does not use FactoryFinder for anything. Only thing I think does is the Stax API. Nothing to do with Woodstox; same would apply to JDK6-bundled Stax implementation (Sun Sjsxp). Ditto for OSGi: Stax/SAX/JAXP all use introspection mechanism that does not work well with OSGi. This is the same for all implementations. Also -- if and when there are concerns about Woodstox, would it kill you to maybe contact Woodstox project team? It is rather frustrating to find that many have enough time to complain, whine, and hack around things, but not enough to actually take time to try to resolve problems. Most open source packages have competent and friendly maintainers, who can be concated to help resolve issues (or point out that issues are elsewhere as the case may be). Finally: maybe it'd be good to make stax implementation a "provided" dependency: provided by platform or added by users. That way it could use whichever implementation user chose; either the best, or one that container or JDK provides. > Change template parser to not use STAX, as it is not (yet) compatible with > Google App Engine > > > Key: TAP5-713 > URL: https://issues.apache.org/jira/browse/TAP5-713 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.1.0.5 >Reporter: Howard M. Lewis Ship > > The StAX APIs are not on the GAE "white list". > Should be reasonable ot change the code, by using a SAX parser that parses > the template into a list of tokens, and then iterate down the token list as > we do today using StAX. End result will be fewer dependencies to boot. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-713) Change template parser to not use STAX, as it is not (yet) compatible with Google App Engine
[ https://issues.apache.org/jira/browse/TAP5-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729518#action_12729518 ] Tatu Saloranta commented on TAP5-713: - Huh? Woodstox does not use FactoryFinder for anything. Only thing I think does is the Stax API. Nothing to do with Woodstox; same would apply to JDK6-bundled Stax implementation (Sun Sjsxp). Ditto for OSGi: Stax/SAX/JAXP all use introspection mechanism that does not work well with OSGi. This is the same for all implementations. Also -- if and when there are concerns about Woodstox, would it kill you to maybe contact Woodstox project team? It is rather frustrating to find that many have enough time to complain, whine, and hack around things, but not enough to actually take time to try to resolve problems. Most open source packages have competent and friendly maintainers, who can be concated to help resolve issues (or point out that issues are elsewhere as the case may be). Finally: maybe it'd be good to make stax implementation a "provided" dependency: provided by platform or added by users. That way it could use whichever implementation user chose; either the best, or one that container or JDK provides. > Change template parser to not use STAX, as it is not (yet) compatible with > Google App Engine > > > Key: TAP5-713 > URL: https://issues.apache.org/jira/browse/TAP5-713 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.1.0.5 >Reporter: Howard M. Lewis Ship > > The StAX APIs are not on the GAE "white list". > Should be reasonable ot change the code, by using a SAX parser that parses > the template into a list of tokens, and then iterate down the token list as > we do today using StAX. End result will be fewer dependencies to boot. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TAP5-103) provide access to component parameters from within mixins
[ https://issues.apache.org/jira/browse/TAP5-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Zeigler reassigned TAP5-103: --- Assignee: Robert Zeigler > provide access to component parameters from within mixins > - > > Key: TAP5-103 > URL: https://issues.apache.org/jira/browse/TAP5-103 > Project: Tapestry 5 > Issue Type: New Feature >Affects Versions: 5.0.15 >Reporter: Kristian Marinkovic >Assignee: Robert Zeigler > > A mixin can't access the parameters of a component because the Bindings > property of the InternalComponentResourcesImpl class is private and the > respective interface does not provide a access method. > I was trying to create a mixin that would render only the value of a form > element (without the tags) when it was in a certain state. There also might > be use cases where mixins are used to collect data from the components they > are attached and therefore also needs access to the components parameters. > see threads: > http://www.nabble.com/Antwort%3A--T5--how-to-read-the-value-of-a-component-parameter-within-a-mixin-tf4487995.html > http://www.nabble.com/-T5--how-to-read-the-value-of-a-component-parameter-within-a-mixin-tf4487597.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-770) Minor documentation typos
Minor documentation typos - Key: TAP5-770 URL: https://issues.apache.org/jira/browse/TAP5-770 Project: Tapestry 5 Issue Type: Bug Components: documentation Affects Versions: 5.1.0.5 Reporter: Robert Zeigler Priority: Trivial Perusing through the documentation, I've found various typos. This ticket is to keep track of them so I can make sure I fix them all. PageLoaded annotation java docs: "...instantance initialzation time, such as refrerences..." should be "...instance initialization time, such as references". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TAP5-770) Minor documentation typos
[ https://issues.apache.org/jira/browse/TAP5-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Zeigler reassigned TAP5-770: --- Assignee: Robert Zeigler > Minor documentation typos > - > > Key: TAP5-770 > URL: https://issues.apache.org/jira/browse/TAP5-770 > Project: Tapestry 5 > Issue Type: Bug > Components: documentation >Affects Versions: 5.1.0.5 >Reporter: Robert Zeigler >Assignee: Robert Zeigler >Priority: Trivial > > Perusing through the documentation, I've found various typos. This ticket is > to keep track of them so I can make sure I fix them all. > PageLoaded annotation java docs: > "...instantance initialzation time, such as refrerences..." should be > "...instance initialization time, such as references". -- 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 ] Howard M. Lewis Ship updated TAP5-769: -- Summary: JavaScript aggregation can be inefficient across multiple pages with different JS requirements (was: Combination of JavaScript is flawed) > 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 > > 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-tabpanel&focusedCommentId=12729303#action_12729303 ] Howard M. Lewis Ship commented on TAP5-769: --- I'm not sure if there's an issue for this, but a suggestion was floating around that the core JS stack be combined separately from the per-page JS. Thus you'd have one request for prototype/scripaculous/events/tapestry/etc. and a second request anything specific per-page. An advantage here is that the core stack could have a shorter url, something like: /assets/virtual/x.y.z/core.js Since the core JS library paths would not need to be encoded into the name, the per-page virtual script would also be shorter. I can also see an easy way to extend the base stack to include additional JS files; this would pre-emptively include the JS library as part of the core; so if you are using, say, Modalbox across many pages, it would be in core (even for pages that don't actually use it). 5.1 introduces a service responsible for encoding binary streams into MIME (for inclusion in the URL); that's where your 919 characters come from. The intent is that the service could be overridden to store the data on the server side (in the main database, or some kind of embedded database) and send just a token or id to the client side. That has a lot of implications for a clustered application, which is why the default behavior is to encode the data into the MIME stream and let it live on the client. > 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] Commented: (TAP5-769) Combination of JavaScript is flawed
[ https://issues.apache.org/jira/browse/TAP5-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] Updated: (TAP5-769) Combination of JavaScript is flawed
[ https://issues.apache.org/jira/browse/TAP5-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Blower updated TAP5-769: - Description: 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. was: 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 have 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 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) 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 each page of a site. This means that the client browser has to download & cache lots of large JS multiple times (prototype, scriptaculous, tapestry etc) 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 should 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. 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
[jira] Created: (TAP5-769) Combination of JavaScript is flawed
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 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 have 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 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) 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 each page of a site. This means that the client browser has to download & cache lots of large JS multiple times (prototype, scriptaculous, tapestry etc) 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 should 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. 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: H4sIALVW7ZLSMBTFGX0Rx$002fFrZgk7gvjDH0plBWdRho6ujjpOmt7ChTTpJmlZfBYfwVfzHUwKRRiFXUrlV0hPzs39OKf9$002bat253utdrtmf3drjwnVGowmmilMDGUpl6kmrfppvVFvkURJI80igfpU1$002br7sVu7Dv9wPx6iCJjJkfcKpKEJaKMWa1Cx4VD3C1TAKZsFqMI1bL3jcCfXsp3EoDUdQx78cwFn3C4SaiaEsfDps0bUeNJstprtoE2YjF0tLlN7nNAksWCpgGNApjSjy$002fzIUCZpcoEilPNzFLNqyfuCo4APlGNIDUrhyL2C3B76J20iBQj7PF4o0EAVmxAfx6Iv3mWgOM2r2i1BMlQQgQLBQLtMHQ2tKlGO44nJEOZkqv$002f8cSFGR4XYyGQj$002bxelS3gmVewYnu9lyNYNI6kGJWhc9FAqd$002fpNifieAmpgqGSEHDZy$002bXZYfXIT2N2HpfQxcW0o1i7K$002b6q60BeR7KRBwHNzebTfLJgURkmea6q9U99FlBivUNiapka6gBwMHC$002fGFanHpab20i8tubdB3rlpJwsNObfw02BqTfActSk9jTQDP186hi9VdWcEOuVGnyE3VulhJ5$002bw1wfm2MMwBNFDM6BqBsqfo1le8zgpb0ypJ$002bUMlz7eu$002bnlMtQp5SFoq2MyoCg8O1z2yciZzUG$002busXUvbRrT$002fI0Fgcpe4vEnuc00WgHzLeDsTL6B9e8ea2hgCrlwtYEbv3YNQOvrM2MqBjD1jC4OJ$002f$002by5jlbfxaFfVgMVppxJuA$002fTqQV47$002bYwmJ$002fc10gWby1jpihGz9Nq7MGLsi9O33yZL2NyNGzuevCQAA.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-678) Allow blackbird to be disabled in production mode
[ https://issues.apache.org/jira/browse/TAP5-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729176#action_12729176 ] Andy Blower commented on TAP5-678: -- I think it's important to be able to completely disable the blackbird console for production to avoid the unnecessary .css and .js downloads (12.1K and 7.1K) for live sites. > Allow blackbird to be disabled in production mode > - > > Key: TAP5-678 > URL: https://issues.apache.org/jira/browse/TAP5-678 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.2 >Reporter: Paudi Moriarty > > blackbird's use of F2 to show the console is interfering with our application > which uses F-keys as hotkeys to access various parts of the application. > It should be possible to either completely disable blackbird in production > mode (avoiding unnecessary .css and .js downloads) or at least disable the > console hotkey. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
