[jira] Created: (TAP5-640) DOM manipulation no longer allowed during rendering
DOM manipulation no longer allowed during rendering --- Key: TAP5-640 URL: https://issues.apache.org/jira/browse/TAP5-640 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.2 Reporter: Dan Adams We have a number of utilities that do DOM manipulation while the page is rendering. This is often a lot easier than doing it after render and results in more concise code. An example is if you have a list of elements: foo After each LI renders, do something like this: if (element.getChildren().isEmpty()) element.remove(); It will work for the first empty LI and throw a NPE on the second empty LI because the container inside the element is null (which is odd since it just rendered into a container). But if you wait till after the LIs have all rendered you can loop back and do this safely. However, it's much less readable code and is a real bummer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-639) Inlcude a coercion from Hibernate's Criteria object to a GridDataSource
[ https://issues.apache.org/jira/browse/TAP5-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697603#action_12697603 ] Robert Zeigler commented on TAP5-639: - I did something like this for similar data structues in the tapestry5-cayenne library (they don't have a criteria query, but they have a SelectQuery, which is similar); came out pretty. :) > Inlcude a coercion from Hibernate's Criteria object to a GridDataSource > --- > > Key: TAP5-639 > URL: https://issues.apache.org/jira/browse/TAP5-639 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-hibernate >Affects Versions: 5.1.0.4 >Reporter: Howard M. Lewis Ship > > Seems like a wrapper around a base Criteria could (form there) add in sorting > and pagination quite seamlessly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-639) Inlcude a coercion from Hibernate's Criteria object to a GridDataSource
Inlcude a coercion from Hibernate's Criteria object to a GridDataSource --- Key: TAP5-639 URL: https://issues.apache.org/jira/browse/TAP5-639 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-hibernate Affects Versions: 5.1.0.4 Reporter: Howard M. Lewis Ship Seems like a wrapper around a base Criteria could (form there) add in sorting and pagination quite seamlessly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-621) When using PageTester, an exception in the page is hidden by an exception rendering the exception report page
[ https://issues.apache.org/jira/browse/TAP5-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697596#action_12697596 ] Andy Blower commented on TAP5-621: -- This is still an issue, I now get this when using the PageTester. So the actual problem is still being hidden. org.apache.tapestry5.internal.services.RenderQueueException: Render queue error in BeginRender[core/ExceptionReport:renderobject]: Request: method getHeaderNames() not yet implemented by TestableRequestImpl. [at classpath:org/apache/tapestry5/corelib/pages/ExceptionReport.tml, line 24] at org.apache.tapestry5.internal.services.RenderQueueImpl.run(RenderQueueImpl.java:86) at org.apache.tapestry5.internal.services.PageRenderQueueImpl.render(PageRenderQueueImpl.java:121) at $PageRenderQueue_1208c28466c.render($PageRenderQueue_1208c28466c.java) at $PageRenderQueue_1208c28466b.render($PageRenderQueue_1208c28466b.java) at org.apache.tapestry5.internal.services.MarkupRendererTerminator.renderMarkup(MarkupRendererTerminator.java:37) at org.apache.tapestry5.services.TapestryModule$27.renderMarkup(TapestryModule.java:1752) at $MarkupRenderer_1208c284670.renderMarkup($MarkupRenderer_1208c284670.java) at org.apache.tapestry5.services.TapestryModule$26.renderMarkup(TapestryModule.java:1733) at $MarkupRenderer_1208c284670.renderMarkup($MarkupRenderer_1208c284670.java) at org.apache.tapestry5.services.TapestryModule$25.renderMarkup(TapestryModule.java:1715) at $MarkupRenderer_1208c284670.renderMarkup($MarkupRenderer_1208c284670.java) at org.apache.tapestry5.services.TapestryModule$24.renderMarkup(TapestryModule.java:1701) at $MarkupRenderer_1208c284670.renderMarkup($MarkupRenderer_1208c284670.java) at org.apache.tapestry5.services.TapestryModule$23.renderMarkup(TapestryModule.java:1682) at $MarkupRenderer_1208c284670.renderMarkup($MarkupRenderer_1208c284670.java) at org.apache.tapestry5.services.TapestryModule$22.renderMarkup(TapestryModule.java:1663) at $MarkupRenderer_1208c284670.renderMarkup($MarkupRenderer_1208c284670.java) at org.apache.tapestry5.internal.test.CaptureRenderedDocument.renderMarkup(CaptureRenderedDocument.java:39) at $MarkupRenderer_1208c284670.renderMarkup($MarkupRenderer_1208c284670.java) at $MarkupRenderer_1208c28466a.renderMarkup($MarkupRenderer_1208c28466a.java) at org.apache.tapestry5.internal.services.PageMarkupRendererImpl.renderPageMarkup(PageMarkupRendererImpl.java:64) at $PageMarkupRenderer_1208c284666.renderPageMarkup($PageMarkupRenderer_1208c284666.java) at org.apache.tapestry5.internal.services.PageResponseRendererImpl.renderPageResponse(PageResponseRendererImpl.java:61) at $PageResponseRenderer_1208c28460b.renderPageResponse($PageResponseRenderer_1208c28460b.java) at org.apache.tapestry5.internal.services.DefaultRequestExceptionHandler.handleRequestException(DefaultRequestExceptionHandler.java:77) at $RequestExceptionHandler_1208c2845f5.handleRequestException($RequestExceptionHandler_1208c2845f5.java) at org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:42) at $RequestHandler_1208c2845f8.service($RequestHandler_1208c2845f8.java) at org.apache.tapestry5.services.TapestryModule$4.service(TapestryModule.java:782) at $RequestHandler_1208c2845f8.service($RequestHandler_1208c2845f8.java) at org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:771) at $RequestHandler_1208c2845f8.service($RequestHandler_1208c2845f8.java) at org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:85) at $RequestHandler_1208c2845f8.service($RequestHandler_1208c2845f8.java) at com.proquest.apps.corelib.AppCoreLibModule$4.service(AppCoreLibModule.java:209) at $RequestFilter_1208c2845ef.service($RequestFilter_1208c2845ef.java) at $RequestHandler_1208c2845f8.service($RequestHandler_1208c2845f8.java) at org.apache.tapestry5.internal.test.EndOfRequestCleanupFilter.service(EndOfRequestCleanupFilter.java:42) at $RequestHandler_1208c2845f8.service($RequestHandler_1208c2845f8.java) at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:90) at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:81) at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85) at org.apache.tapestry5.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:103) at $RequestHandler_1208c2845f8.service($RequestHandler_1208c2845f8.java) at $RequestHandler_1208c2845e3.servic
[jira] Commented: (TAP5-633) Allow page classes to have a "Page" suffix that is not included in the URL
[ https://issues.apache.org/jira/browse/TAP5-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697561#action_12697561 ] Paul Field commented on TAP5-633: - Nice idea but unfortunately, then I will have a lot of packages that contain just one class. The core part of our app is primarily a collection of read-only pages centred on the domain objects: Company, Analyst, Region, Sector, Statistics and so on. As I say, the business naturally refer to these as the "Company Page" and "Analyst Page" etc... From a Domain Driven Design point-of-view I like the idea that the Java classes are named after the business domain terms. Interestingly as we write financial applications "Index" has a very specific meaning so a "Company Index" means something to the business and IndexIndex would be really confusing :-) One of our other apps does have an Index Page (in the business sense). > Allow page classes to have a "Page" suffix that is not included in the URL > -- > > Key: TAP5-633 > URL: https://issues.apache.org/jira/browse/TAP5-633 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.1.0.2 >Reporter: Paul Field >Priority: Minor > > I have an application with a lot of read-only pages. For example, I have a > page that shows a company and I would like a URI such as: /company/1234 > However, if I name the page class "Company" then I get a naming clash with > the domain object "Company". What I would like to do is call the Tapestry 5 > class "CompanyPage" - after all, that is what the class represents and it's > certainly how the team refers to that thing internally and with our business > (i.e. "Have you seen the new company page?"). > So, please could the ComponentClassResolverImpl remove the suffix "Page" (if > it exists) from the class name when it constructs the logical page name? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-633) Allow page classes to have a "Page" suffix that is not included in the URL
[ https://issues.apache.org/jira/browse/TAP5-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697535#action_12697535 ] Howard M. Lewis Ship commented on TAP5-633: --- Create a package named company and create a class CompanyIndex. Tapestry will strip off "Company" because it matches the package name, and "Index" because its by itself, resulting in a base URL of "/company" to which the page activation context will be added. > Allow page classes to have a "Page" suffix that is not included in the URL > -- > > Key: TAP5-633 > URL: https://issues.apache.org/jira/browse/TAP5-633 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.1.0.2 >Reporter: Paul Field >Priority: Minor > > I have an application with a lot of read-only pages. For example, I have a > page that shows a company and I would like a URI such as: /company/1234 > However, if I name the page class "Company" then I get a naming clash with > the domain object "Company". What I would like to do is call the Tapestry 5 > class "CompanyPage" - after all, that is what the class represents and it's > certainly how the team refers to that thing internally and with our business > (i.e. "Have you seen the new company page?"). > So, please could the ComponentClassResolverImpl remove the suffix "Page" (if > it exists) from the class name when it constructs the logical page name? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-638) Support for uploading files using AJAX
[ https://issues.apache.org/jira/browse/TAP5-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hugo Palma updated TAP5-638: Summary: Support for uploading files using AJAX (was: Support for ajax requests) > Support for uploading files using AJAX > -- > > Key: TAP5-638 > URL: https://issues.apache.org/jira/browse/TAP5-638 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-upload >Reporter: Hugo Palma > > If the upload component is included on a form that does a partial update(has > the zone parameter set) the value property isn't updated with the > UploadedFile instance. > So it seems that this component upload doesn't support ajax. It would be > great if it was possible to upload a file using AJAX. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-638) Support for ajax requests
Support for ajax requests - Key: TAP5-638 URL: https://issues.apache.org/jira/browse/TAP5-638 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-upload Reporter: Hugo Palma If the upload component is included on a form that does a partial update(has the zone parameter set) the value property isn't updated with the UploadedFile instance. So it seems that this component upload doesn't support ajax. It would be great if it was possible to upload a file using AJAX. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-577) TAP5-422 changes break persistent locale backwards compatibility.
[ https://issues.apache.org/jira/browse/TAP5-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Blower updated TAP5-577: - Attachment: T5.1persistentLocale.txt It looks rather like no one else is bothered by this, so I've gone ahead and converted my app's locale persistence to work in T5.1 and I'm attaching the changes I made to our module to support custom implementations of the PersistentLocale service. Howard, can you check that I've not missed a trick here please? Also, I was wondering if having a method in LocalizationSetter that allows a Locale to be passed would be a good idea. (to remove the conversion to String and back again which occurs for every request) The only other slight annoyance I have with this is PersistentLocale.set() being constantly called by the LocalizationSetter for each request, this doesn't fit in with the old way that the PersistentLocale service was used. I think that only executing persistentLocale.set(locale); (line 113) if ENCODE_LOCALE_INTO_PATH is true would be a nice little improvement. > TAP5-422 changes break persistent locale backwards compatibility. > - > > Key: TAP5-577 > URL: https://issues.apache.org/jira/browse/TAP5-577 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.1.0.0, 5.1.0.1 >Reporter: Andy Blower >Priority: Critical > Attachments: T5.1persistentLocale.txt > > > I think that the changes made in T5.1 for TAP5-422 break backwards > compatibility with T5.0's locale persistence. In T5.0 it was a simple matter > to override the default cookie persistence by creating a custom > implementation of the PersistentLocale service and contributing it to be used > instead of the standard internal T5 implementation. > The TAP5-422 changes broke backwards compatibility because anyone who's > created their own implementation of PersistentLocale, or just wants the 5.0 > cookie persistence behaviour, would have found that it's a lot more work and > involves some heavy changes to Tapestry internals. Now with the recent > changes for TAP5-418 (committed yesterday), the situation had been alleviated > somewhat by allowing the the hard-wired URl locale persistence to be switched > off using a new symbol. > However, I still think that this breaks backwards compatibility in two ways: > 1) By changing the default behaviour of locale persistence so that anyone > relying on the locale persistence behaviour of 5.0 will have to make > non-trivial changes when they upgrade to 5.1 to keep the same operation. > 2) By requiring so much work for anyone wanting to keep the 5.0 cookie > persistence behaviour or define their own custom locale persistence. (In 5.0 > it was easy to figure out and implement a custom locale persistence method) > From my analysis of the changes made by TAP5-422 & TAP5-418, I think anyone > wanting non-URL based locale persistence will need to do the following when > upgrading from 5.0 to 5.1: > 1) Set the ENCODE_LOCALE_INTO_PATH symbol to false. > 2) Create an implementation of PersistentLocale and contribute it to the IOC. > (copied from the standard 5.0 code if the old default cookie persistence is > desired) > 3) Create a custom filter written and created to do the same job as the 5.0 > LocalizationFilter and contribute it to the IOC RequestHandler. This filter > will need to call the LocalizationSetter setLocaleFromLocaleName() method > instead of the old setThreadLocale() method. > My suggested resolution would be to re-instate the 5.0 cookie persistence > (LocalizationFilter & PersistentLocaleImpl) and have the new > ENCODE_LOCALE_INTO_PATH symbol default to false allowing 5.1 to work the same > way as 5.0 out of the box. If the symbol is set to true, then the > LocalizationFilter is disabled (not contributed to RequestHandler) and the > PersistentLocale service will need to just store the locale (not set it in a > cookie) for later use by LinkSourceImpl. > LocalizationSetterImpl.setLocaleFromLocaleName(String localeName) would also > need changing back to overriding the passed localeName if a persistent one > had been set into the PersistentLocale service. There may by a much better > solution than this as I've not spent much time on it, but I though I should > try to be helpful as possible. > (It should be noted that this is purely a product of my analysis of the 5.1 > code, I have not found the time to actually run T5.1 and test this out - I > should be able to do this in about a week and a half, but I'm currently > approaching a major milestone deadline. Hopefully someone else will find the > time to prove or disprove my hypothesis.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to
[jira] Updated: (TAP5-637) There should be a javascript counterpart for the URLEncoder service
[ https://issues.apache.org/jira/browse/TAP5-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hugo Palma updated TAP5-637: Component/s: tapestry-core Priority: Minor (was: Major) Description: This is very useful if you want to build event urls in javascript. Summary: There should be a javascript counterpart for the URLEncoder service (was: There should be a javascript counterpart for the URLE) > There should be a javascript counterpart for the URLEncoder service > --- > > Key: TAP5-637 > URL: https://issues.apache.org/jira/browse/TAP5-637 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core >Reporter: Hugo Palma >Priority: Minor > Attachments: url-encoder.js > > > This is very useful if you want to build event urls in javascript. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-637) There should be a javascript counterpart for the URLEncoder service
[ https://issues.apache.org/jira/browse/TAP5-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hugo Palma updated TAP5-637: Attachment: url-encoder.js This is my implementation of the URLEncoder service. Feel free to use and/or change it and incorporate in the framework. > There should be a javascript counterpart for the URLEncoder service > --- > > Key: TAP5-637 > URL: https://issues.apache.org/jira/browse/TAP5-637 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core >Reporter: Hugo Palma >Priority: Minor > Attachments: url-encoder.js > > > This is very useful if you want to build event urls in javascript. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-637) There should be a javascript counterpart for the URLE
There should be a javascript counterpart for the URLE - Key: TAP5-637 URL: https://issues.apache.org/jira/browse/TAP5-637 Project: Tapestry 5 Issue Type: New Feature Reporter: Hugo Palma -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-469) ResponseCompressionAnalyzer: application/json responses should be uncompressable by default
[ https://issues.apache.org/jira/browse/TAP5-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697421#action_12697421 ] Paudi Moriarty commented on TAP5-469: - I agree. I spent as much time as I could on it and had to move on. Let us know if you find out more. > ResponseCompressionAnalyzer: application/json responses should be > uncompressable by default > --- > > Key: TAP5-469 > URL: https://issues.apache.org/jira/browse/TAP5-469 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.1.0.0 >Reporter: Paudi Moriarty >Assignee: Howard M. Lewis Ship > Fix For: 5.1.0.3 > > > GZip compressed responses with Content-Type: application/json are not handled > correctly by at least Firefox or IE and should be configured as > uncompressable by default > When the response is received in prototype's Ajax.Request > response.responseText is "". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
