[Trinidad] UIXGroup inside HtmlRowLayout is leading to INVALID HTML if it contains HtmlCellFormat(s)
Hi all, it would be nice/helpful if RowLayoutRenderer would overwrite encodeAllChildren(...) in that way, that for UIXGroup it should not pass the UIXGroup itself to encodeChild(...), but the children of the UIXGroup. This would have the result, that one could put several columns into one UIXGroup and set them all to rendered = false by just setting the group to rendered = false. This is not possible at the moment, because the overwrite of encodeChild(...) in RowLayoutRenderer renders td for all components ecxept HtmlCellFormat, which leeds to INVALID HTML: if you put columns into a UIXGroup inside HtmlRowLayout. Please tell me if you would except this change if I would submit such a patch or if this is the wrong approach to fix the problem/issue. Best regards Marco Grimm
Re: MyFaces 2.0 development going forward
jankeesvanan...@gmail.com schrieb: I'm currently working on the annotation processing stuff (@ManagedBean, @ManagedProperty...). Already made a first attempt for the managed beans, but there is still some work to do (converters, components, event listeners, etc). I hope I can apply the same logic for those other components as well. With Werner working on Ajax and Simon on Facelets, we already cover a large portion of JSF2. Facelets is big, though, since it also contains tags for all components, EZComp, JSF2-Facelets/Original-Facelets switching, etc... Resource handling/relocation is also a mandatory requirement for Ajax to work. My main problem the last few weeks was that I was assigned to another task which bound me for 100% I hope to have again at least one day per week beginning from this week to finish the client side ajax part. We are on the client side currently at 70% :-), most of the roundtripping is implemented on the client side, the response handling still is missing! Btw. I ditched the Trinidad xhr code (I made it switchable so you for now still can use it). The reason was, the Trinidad code had so many things in, which is not needed by the specs which made the code hard to maintain, that a small clean room transport made more sense to keep the codebase leaner. Some parts of the Trinidad xhr code still live in the new codebase, the form value encoding for instance. But for now there is not too much needed from the Trinidad codebase. I have not seen the latest spec, but the entire iframe aspects were not there, because no direct form submit was done, xhr transport only and that one queued and asynchronously only. By removing the trinidad codebase, I could trim the entire XHR codebase down by 70%, so it made sense to do it! For now I have both transports with a small adapter layer on top of it to hook it into jsf2 but I am not sure if we keep the Trinidad codebase. As for the server side, the main issue there is we have to do a specialized responsewriter, which pretty much Trinidad does already! But I do not consider that too much work! Werner
[jira] Issue Comment Edited: (TOMAHAWK-596) Duplicate id exception for HtmlDataScrollerRenderer
[ https://issues.apache.org/jira/browse/TOMAHAWK-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12678043#action_12678043 ] milan_majercik edited comment on TOMAHAWK-596 at 3/2/09 9:37 AM: - Attached is a fix that sorted out this issue in portlet environment. The fix prevents repeated addition if HTML link component to the data scroller that was a cause of having duplicate element inside the data scroller component. was (Author: milan_majercik): This sorted out the issue in portlet environment Duplicate id exception for HtmlDataScrollerRenderer --- Key: TOMAHAWK-596 URL: https://issues.apache.org/jira/browse/TOMAHAWK-596 Project: MyFaces Tomahawk Issue Type: Bug Components: Data Scroller Affects Versions: 1.1.3 Environment: Linux, Windows Reporter: Ryan Wynn Attachments: datascroller-issue.txt, HtmlDataScrollerRenderer.java, HtmlDataScrollerRenderer.java.example, HtmlDataScrollerRenderer.patch, HtmlDataScrollerRenderer.patch In a portlet environment a non-faces request produces an exception when the faces tree is rendered if the faces tree contains a DataScroller component. The HtmlDataScroller renderer actually renders its children twice in this case, once in the encodeChildren method and once in the encodeEnd method. Since rendering of the children is taken care of in encodeEnd I made the encodeChildren method a no-op. Also, although the CommandLinks which are rendered as children are marked as transient, they see to stick around. I put a check in the getLink methods to make sure that the links are not added twice. This seems to fix the duplicate id exception, but it might be necessary to further investigate why they are sticking around in the first place. -- 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: (TOMAHAWK-596) Duplicate id exception for HtmlDataScrollerRenderer
[ https://issues.apache.org/jira/browse/TOMAHAWK-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12678043#action_12678043 ] milan_majercik edited comment on TOMAHAWK-596 at 3/2/09 9:39 AM: - Attached is a fix that sorted out this issue in portlet environment. The fix prevents repeated addition if HTML link component to the data scroller that was a cause of having duplicate element inside the data scroller component. The DIFF file was generated against version 1.1.8 was (Author: milan_majercik): Attached is a fix that sorted out this issue in portlet environment. The fix prevents repeated addition if HTML link component to the data scroller that was a cause of having duplicate element inside the data scroller component. Duplicate id exception for HtmlDataScrollerRenderer --- Key: TOMAHAWK-596 URL: https://issues.apache.org/jira/browse/TOMAHAWK-596 Project: MyFaces Tomahawk Issue Type: Bug Components: Data Scroller Affects Versions: 1.1.3 Environment: Linux, Windows Reporter: Ryan Wynn Attachments: datascroller-issue.txt, HtmlDataScrollerRenderer.java, HtmlDataScrollerRenderer.java.example, HtmlDataScrollerRenderer.patch, HtmlDataScrollerRenderer.patch In a portlet environment a non-faces request produces an exception when the faces tree is rendered if the faces tree contains a DataScroller component. The HtmlDataScroller renderer actually renders its children twice in this case, once in the encodeChildren method and once in the encodeEnd method. Since rendering of the children is taken care of in encodeEnd I made the encodeChildren method a no-op. Also, although the CommandLinks which are rendered as children are marked as transient, they see to stick around. I put a check in the getLink methods to make sure that the links are not added twice. This seems to fix the duplicate id exception, but it might be necessary to further investigate why they are sticking around in the first place. -- 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: (TOMAHAWK-596) Duplicate id exception for HtmlDataScrollerRenderer
[ https://issues.apache.org/jira/browse/TOMAHAWK-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12678043#action_12678043 ] milan_majercik edited comment on TOMAHAWK-596 at 3/2/09 9:39 AM: - Attached is a fix that sorted out this issue in portlet environment. The fix prevents repeated addition of HTML link component to the data scroller that was a cause of having duplicate element inside the data scroller component. The DIFF file was generated against version 1.1.8 was (Author: milan_majercik): Attached is a fix that sorted out this issue in portlet environment. The fix prevents repeated addition if HTML link component to the data scroller that was a cause of having duplicate element inside the data scroller component. The DIFF file was generated against version 1.1.8 Duplicate id exception for HtmlDataScrollerRenderer --- Key: TOMAHAWK-596 URL: https://issues.apache.org/jira/browse/TOMAHAWK-596 Project: MyFaces Tomahawk Issue Type: Bug Components: Data Scroller Affects Versions: 1.1.3 Environment: Linux, Windows Reporter: Ryan Wynn Attachments: datascroller-issue.txt, HtmlDataScrollerRenderer.java, HtmlDataScrollerRenderer.java.example, HtmlDataScrollerRenderer.patch, HtmlDataScrollerRenderer.patch In a portlet environment a non-faces request produces an exception when the faces tree is rendered if the faces tree contains a DataScroller component. The HtmlDataScroller renderer actually renders its children twice in this case, once in the encodeChildren method and once in the encodeEnd method. Since rendering of the children is taken care of in encodeEnd I made the encodeChildren method a no-op. Also, although the CommandLinks which are rendered as children are marked as transient, they see to stick around. I put a check in the getLink methods to make sure that the links are not added twice. This seems to fix the duplicate id exception, but it might be necessary to further investigate why they are sticking around in the first place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Tobago] Tabgroup y tab looks like windows tabs
Hello Salvador, I don't use windows. Can you create an issue with an attachment of an example screenshot, please. Regards Bernd Bravo Villegas Salvador Francisco schrieb: HI all, I need to make that the Tobago Tabgroup look like windows tabs, that all the tabs I include into the tabgroup been seen in the same window and not use the '' and '' buttons to move into the tabs. Is this possible??? Regards, Salvador B
[jira] Issue Comment Edited: (TOMAHAWK-596) Duplicate id exception for HtmlDataScrollerRenderer
[ https://issues.apache.org/jira/browse/TOMAHAWK-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12678043#action_12678043 ] milan_majercik edited comment on TOMAHAWK-596 at 3/2/09 9:56 AM: - Attached is a fix that sorted out this issue in portlet environment. The fix prevents repeated addition of HTML link component to the data scroller that was a cause of having duplicate element inside the data scroller component. The DIFF file was generated against version 1.1.8 The difference with the original patch issued by Ryan Wynn is that it doesn't comment out the the encodeChildren method although i think there is an ample reason for it as the data scroller is not supposed to have any children and UICommand components that wrap everything inside facets are not component children was (Author: milan_majercik): Attached is a fix that sorted out this issue in portlet environment. The fix prevents repeated addition of HTML link component to the data scroller that was a cause of having duplicate element inside the data scroller component. The DIFF file was generated against version 1.1.8 Duplicate id exception for HtmlDataScrollerRenderer --- Key: TOMAHAWK-596 URL: https://issues.apache.org/jira/browse/TOMAHAWK-596 Project: MyFaces Tomahawk Issue Type: Bug Components: Data Scroller Affects Versions: 1.1.3 Environment: Linux, Windows Reporter: Ryan Wynn Attachments: datascroller-issue.txt, HtmlDataScrollerRenderer.java, HtmlDataScrollerRenderer.java.example, HtmlDataScrollerRenderer.patch, HtmlDataScrollerRenderer.patch In a portlet environment a non-faces request produces an exception when the faces tree is rendered if the faces tree contains a DataScroller component. The HtmlDataScroller renderer actually renders its children twice in this case, once in the encodeChildren method and once in the encodeEnd method. Since rendering of the children is taken care of in encodeEnd I made the encodeChildren method a no-op. Also, although the CommandLinks which are rendered as children are marked as transient, they see to stick around. I put a check in the getLink methods to make sure that the links are not added twice. This seems to fix the duplicate id exception, but it might be necessary to further investigate why they are sticking around in the first place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Orchestra 1.3.1 release candidate
Hi All, I think it's time to release an update to Orchestra Core; we have about half-a-dozen minor/medium bugs fixed. Therefore I have created a release candidate for orchestra-core 1.3.1. Please have a look at these artifacts and vote: [1] http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.3.1 [2] http://people.apache.org/~skitching/orchestra-core-1.3.1/index.html [3] https://svn.apache.org/repos/asf/myfaces/orchestra/branches/core-1_3_1-prepare/RELEASE-NOTES.txt Note that the link from the site to the 1.3.1 release notes isn't there yet - it can't be done until after the vote has passed and the release-branch has been made a tag :-). But that's just a trivial site update.. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks! Simon
[jira] Updated: (TRINIDAD-1411) maven-jdev-plugin has been updated for JDeveloper 11.1.1.1.0
[ https://issues.apache.org/jira/browse/TRINIDAD-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Kind updated TRINIDAD-1411: Status: Patch Available (was: Open) maven-jdev-plugin has been updated for JDeveloper 11.1.1.1.0 Key: TRINIDAD-1411 URL: https://issues.apache.org/jira/browse/TRINIDAD-1411 Project: MyFaces Trinidad Issue Type: Improvement Components: Plugins Affects Versions: 1.2.9-plugins Reporter: Gary Kind I have updated the maven-jdev-plugin so that it works correctly for JDeveloper 11.1.1.1.0 -- that is, it generates .jws and .jpr files that do not have to be migrated by JDeveloper before being used by JDeveloper. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1411) maven-jdev-plugin has been updated for JDeveloper 11.1.1.1.0
maven-jdev-plugin has been updated for JDeveloper 11.1.1.1.0 Key: TRINIDAD-1411 URL: https://issues.apache.org/jira/browse/TRINIDAD-1411 Project: MyFaces Trinidad Issue Type: Improvement Components: Plugins Affects Versions: 1.2.9-plugins Reporter: Gary Kind I have updated the maven-jdev-plugin so that it works correctly for JDeveloper 11.1.1.1.0 -- that is, it generates .jws and .jpr files that do not have to be migrated by JDeveloper before being used by JDeveloper. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1411) maven-jdev-plugin has been updated for JDeveloper 11.1.1.1.0
[ https://issues.apache.org/jira/browse/TRINIDAD-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson updated TRINIDAD-1411: -- Resolution: Fixed Fix Version/s: 1.2.9-plugins Status: Resolved (was: Patch Available) Applied patch maven-jdev-plugin has been updated for JDeveloper 11.1.1.1.0 Key: TRINIDAD-1411 URL: https://issues.apache.org/jira/browse/TRINIDAD-1411 Project: MyFaces Trinidad Issue Type: Improvement Components: Plugins Affects Versions: 1.2.9-plugins Reporter: Gary Kind Fix For: 1.2.9-plugins I have updated the maven-jdev-plugin so that it works correctly for JDeveloper 11.1.1.1.0 -- that is, it generates .jws and .jpr files that do not have to be migrated by JDeveloper before being used by JDeveloper. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [VOTE] Orchestra 1.3.1 release candidate
+0 (I trust you made a high quality package again :-) ) -Original Message- From: Simon Kitching [mailto:skitch...@apache.org] Sent: Monday, March 02, 2009 9:58 PM To: MyFaces Development Subject: [VOTE] Orchestra 1.3.1 release candidate Hi All, I think it's time to release an update to Orchestra Core; we have about half-a-dozen minor/medium bugs fixed. Therefore I have created a release candidate for orchestra-core 1.3.1. Please have a look at these artifacts and vote: [1] http://people.apache.org/builds/myfaces/m2-staging- repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.3.1 [2] http://people.apache.org/~skitching/orchestra-core-1.3.1/index.html [3] https://svn.apache.org/repos/asf/myfaces/orchestra/branches/core- 1_3_1-prepare/RELEASE-NOTES.txt Note that the link from the site to the 1.3.1 release notes isn't there yet - it can't be done until after the vote has passed and the release- branch has been made a tag :-). But that's just a trivial site update.. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks! Simon
