[jira] Created: (TAP5-776) Tapestry.FormFragment (client side) should be refactored to be easier to modify
Tapestry.FormFragment (client side) should be refactored to be easier to modify --- Key: TAP5-776 URL: https://issues.apache.org/jira/browse/TAP5-776 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Howard M. Lewis Ship It would be nice if: a) The DOM element has a property pointing to the Tapestry.FormInjector object. I.e. $T(div).formFragment. b) Tapestry.FormFragment had methods for adding new content (ala FormInjector) above or below the existing FormFragment. c) implicit in above: mix and match of FormInjector and FormFragment, to allow easier ability to build AjaxFormLoop with buttons to add new rows above or below existing rows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-775) AjaxFormLoop should expose (via properties and/or a method on AjaxFormLoopContext) the id of the FormInjector or FormFragment that is rendering (to faciliate JavaScript gene
AjaxFormLoop should expose (via properties and/or a method on AjaxFormLoopContext) the id of the FormInjector or FormFragment that is rendering (to faciliate JavaScript generation) Key: TAP5-775 URL: https://issues.apache.org/jira/browse/TAP5-775 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.0.19 Reporter: Howard M. Lewis Ship Context: trying to make FormFragments within an AjaxFormLoop draggable (for re-ordering purposes). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-774) Initialization JavaScript needs help when order counts
Initialization JavaScript needs help when order counts -- Key: TAP5-774 URL: https://issues.apache.org/jira/browse/TAP5-774 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Howard M. Lewis Ship Tapestry currently has no API to control in what order initialization JavaScript occurs; in fact, much of the initialization (when using RenderSupport.addInit()) will be in an arbitrary order (determined by Map key traversal, which is unpredictable). It would be nice if there was some control to ensure that certain initializations occurred before or after others. A canonical example is a mixin that adds a confirmation dialog to a link; that event handler for the dialog must come FIRST before any other event handlers for the click event of the link. Since Prototype doesn't seem to provide a way to establish that ordering, Tapestry needs to. RenderSupport.addInit() needs new overrides (or perhaps a new method, addScheduledInit()) where a prioritization is added; the priority is a number; all initializations for a particular priority level occur before initializations for a numerically higher level. The default priority should be some reasonable number (0, 100, 1000 ... but fixed) to make it easier to say "before" or "after" ... much as the CSS z-order property is used. -- 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) 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:comment-tabpanel&focusedCommentId=12729789#action_12729789 ] Howard M. Lewis Ship commented on TAP5-769: --- The file name is really a MIME encoded stream of all the JS library paths; thus it gets bigger as the number of JS files increases. > 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) 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:comment-tabpanel&focusedCommentId=12729711#action_12729711 ] Andy Blower commented on TAP5-769: -- That sounds like a good solution to me (hardly surprising since I suggested it as an alternative solution above) and extending base stack for additional files sounds very good. What data is encoded into the filename? What's it used for? > 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] Created: (TAP5-773) Select component renderer does not allow HTML entities
Select component renderer does not allow HTML entities -- Key: TAP5-773 URL: https://issues.apache.org/jira/browse/TAP5-773 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Andy Blower All ampersands that are returned from getLabel() in an OptionModel get encoded to &. This makes it impossible to use any html entities (— etc) within option labels in selects. This is not that uncommon and should definitely be supported by Tapestry out of the box. It can be fixed by changing line 60 of org.apache.tapestry5.internal.util.SelectModelRender from writer.write(optionModel.getLabel()); to writer.writeRaw(optionModel.getLabel()); This would mean that ampersands will need to be encoded for option labels, but this is at least possible for a developer to do. Currently it's not possible to use entities without using a custom select component, you can't even extend the T5 Select class and override the Render nested class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-772) Strange behaviour when filter is mapped to different location that /*
Strange behaviour when filter is mapped to different location that /* - Key: TAP5-772 URL: https://issues.apache.org/jira/browse/TAP5-772 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Michael Wyraz If the filter is mapped to anything else than /* tapestry is not working correctly anymore. Examples: If I map the filter to /test/*, every page fails with 404 If I map a Servlet to that URL as well, every page renders but all generated links (resources, page links) are wrong (missing /test/). I think this behaviour depends on what request.gatPathInfo() returns: - if no servlet is mapped to the current url, it returns NULL. - otherwise, the uri minus the servlet's path So the result of request.getPathInfo() has nothing to do with the filter and should not be used there. Instead, the filter should have an init param which tells where It is mapped to and create a wraped ServletRequest with a customized getPathInfo(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-771) allow to add a .html to page render requests
[ https://issues.apache.org/jira/browse/TAP5-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729638#action_12729638 ] Thiago H. de Paula Figueiredo commented on TAP5-771: You can (almost easily) implement this using URL rewriting. ;) > allow to add a .html to page render requests > > > Key: TAP5-771 > URL: https://issues.apache.org/jira/browse/TAP5-771 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Reporter: Andy Pahne >Priority: Minor > > A common request is to allow a .html extension for page render requests. It > would be nice when Tapestry also could be configured to add the desired > extension to generated URLs. > For backwards compatibility this behaviour could be turned off by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-771) allow to add a .html to page render requests
allow to add a .html to page render requests Key: TAP5-771 URL: https://issues.apache.org/jira/browse/TAP5-771 Project: Tapestry 5 Issue Type: Improvement Reporter: Andy Pahne A common request is to allow a .html extension for page render requests. It would be nice when Tapestry also could be configured to add the desired extension to generated URLs. For backwards compatibility this behaviour could be turned off by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-771) allow to add a .html to page render requests
[ https://issues.apache.org/jira/browse/TAP5-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Pahne updated TAP5-771: Component/s: tapestry-core Priority: Minor (was: Major) > allow to add a .html to page render requests > > > Key: TAP5-771 > URL: https://issues.apache.org/jira/browse/TAP5-771 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Reporter: Andy Pahne >Priority: Minor > > A common request is to allow a .html extension for page render requests. It > would be nice when Tapestry also could be configured to add the desired > extension to generated URLs. > For backwards compatibility this behaviour could be turned off by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
