[jira] Created: (TRINIDAD-1741) Multiselection in tr:table doesn't work correctly anymore?
Multiselection in tr:table doesn't work correctly anymore? -- Key: TRINIDAD-1741 URL: https://issues.apache.org/jira/browse/TRINIDAD-1741 Project: MyFaces Trinidad Issue Type: Bug Components: Components Environment: XP Home; Tomcat6.14.;jsf1.2;trinidad1.2.13 Reporter: Günter D. Since today i discovered the folowing wich once worked properly. I have several tables with the opportunity for a multiple row selection. Only the first entry in the table works correctly if you mark it as selected or unselected. The SelectionListener is called, everything's fine. But if I choose other rows it works only for the first time you do it. After that I have to click several times to do a deselect of that row and the SelectionListener is never called again??. Select All and Deselect all still work as expected. If I sort the table by another column, so that i get a different first row, this will be the one working properly and the other rows won't. I use IE8, FF3.6 and tried it with FF3.5.6, everywhere the same. Any help would be appreciated. Best Regards -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1742) Add licence header in xhtml files in Trinidad showcase
Add licence header in xhtml files in Trinidad showcase -- Key: TRINIDAD-1742 URL: https://issues.apache.org/jira/browse/TRINIDAD-1742 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha Reporter: Marius Petoi Priority: Trivial Attachments: licenceHeader.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1742) Add licence header in xhtml files in Trinidad showcase
[ https://issues.apache.org/jira/browse/TRINIDAD-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petoi updated TRINIDAD-1742: --- Status: Patch Available (was: Open) Add licence header in xhtml files in Trinidad showcase -- Key: TRINIDAD-1742 URL: https://issues.apache.org/jira/browse/TRINIDAD-1742 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha Reporter: Marius Petoi Priority: Trivial Attachments: licenceHeader.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-72) ASM Type handling
[ https://issues.apache.org/jira/browse/EXTSCRIPT-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-72. -- Resolution: Fixed ASM Type handling - Key: EXTSCRIPT-72 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-72 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz Asm has a set of convenience methods which take care over the type handling we should use that one instead of doing our own string stuff to handle the low level types -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-74) Cleanup the ASP part
[ https://issues.apache.org/jira/browse/EXTSCRIPT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-74. -- Resolution: Fixed Cleanup the ASP part Key: EXTSCRIPT-74 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-74 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz Priority: Minor The ASM part needs some cleanup, we introduce a registry/filter system for the dependency registration -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1741) Multiselection in tr:table doesn't work correctly anymore?
[ https://issues.apache.org/jira/browse/TRINIDAD-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839687#action_12839687 ] Günter D. commented on TRINIDAD-1741: - Sorry for causing trouble, the reason was my filter for injections. Multiselection in tr:table doesn't work correctly anymore? -- Key: TRINIDAD-1741 URL: https://issues.apache.org/jira/browse/TRINIDAD-1741 Project: MyFaces Trinidad Issue Type: Bug Components: Components Environment: XP Professional SP3; Tomcat6.14.;jsf1.2;trinidad1.2.13 Reporter: Günter D. Since today i discovered the following wich once worked properly. I have several tables with the opportunity for a multiple row selection. Only the first entry in the table works correctly if you mark it as selected or unselected. The SelectionListener is called, everything's fine. But if I choose other rows it works only for the first time you do it. After that I have to click several times to do a deselect of that row and the SelectionListener is never called again??. Select All and Deselect all still work as expected. If I sort the table by another column, so that i get a different first row, this will be the one working properly and the other rows won't. I use IE8, FF3.6 and tried it with FF3.5.6, everywhere the same. Any help would be appreciated. Best Regards -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-119) InputDate popup crashes when using extension mapping
[
https://issues.apache.org/jira/browse/TRINIDAD-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839708#action_12839708
]
Joachim Schrod commented on TRINIDAD-119:
-
I can confirm that the problem still exists with MyFaces 1.2.8, Trinidad
1.2.12, and Faceletes 1.1.14.
It can be reproduced by a simple page that just has tr:inputDate
value=#{date.date} label=Default Date:/
as content and an associated bean date.
Ians patch works. One must have a servlet-mapping established from
DEFAULT_SUFFIX to Faces Servlet,
if one has different suffixes for files and URIs.
That was probably Mathias problem, he has to establish a servlet-mapping to
*.xhtml as well, in addition to *.jsf.
InputDate popup crashes when using extension mapping
Key: TRINIDAD-119
URL: https://issues.apache.org/jira/browse/TRINIDAD-119
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.1-core
Environment: Apache Tomcat 6.0.13, JDK 1.6.02, Facelets 1.1.11,
Trinidad 1.2.1, MyFaces 1.2.0, Ajax4jsf 1.0.6
Reporter: Jan-Kees van Andel
Attachments: MyFacesBugFixFilter.java, MyFacesBugFixFilter.java
If I use extension mapping (*.faces), my inputDate component crashes with a
404 when I click on the button.
The message is:
The requested resource (/mblf/__ADFv__) is not available.
When using prefix mapping (/faces/), everything works fine. The URL it
references is:
http://localhost:8080/mblf/faces/__ADFv__?_t=fred_red=cdvalue=118505880loc=en
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-70) Generics not recognized yet in the dependency detector
[ https://issues.apache.org/jira/browse/EXTSCRIPT-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-70. -- Resolution: Fixed Generics not recognized yet in the dependency detector -- Key: EXTSCRIPT-70 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-70 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz Assignee: Werner Punz Generics are not recognized by the dependency detector yet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-119) InputDate popup crashes when using extension mapping
[ https://issues.apache.org/jira/browse/TRINIDAD-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839748#action_12839748 ] Joachim Schrod commented on TRINIDAD-119: - Just confirmed for Trinidad 1.2.13, too. I saw it's announcement just today. Btw, the filter may not be for all URIs (/*), it's sufficient to define it for `/__ADFv__'. InputDate popup crashes when using extension mapping Key: TRINIDAD-119 URL: https://issues.apache.org/jira/browse/TRINIDAD-119 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.1-core Environment: Apache Tomcat 6.0.13, JDK 1.6.02, Facelets 1.1.11, Trinidad 1.2.1, MyFaces 1.2.0, Ajax4jsf 1.0.6 Reporter: Jan-Kees van Andel Attachments: MyFacesBugFixFilter.java, MyFacesBugFixFilter.java If I use extension mapping (*.faces), my inputDate component crashes with a 404 when I click on the button. The message is: The requested resource (/mblf/__ADFv__) is not available. When using prefix mapping (/faces/), everything works fine. The URL it references is: http://localhost:8080/mblf/faces/__ADFv__?_t=fred_red=cdvalue=118505880loc=en -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-75) Add asm package relocation
Add asm package relocation -- Key: EXTSCRIPT-75 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-75 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz We use ASM, we cannot get rid of it since our dependency scan relies on it, to get rid of packaging conflicts probably introduced by other parts of the system we have to relocate asm in the build process via the maven shade plugin: http://maven.apache.org/plugins/maven-shade-plugin/ or via jarjar http://code.google.com/p/jarjar/ One way or the other the com.objectweb.asm hierarchy has to be mapped into org.apache.myfaces.scripting.com.objectweb.asm package, to avoid any namespace collisions with other projects. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Core] Missing f:event tag (Declarative Event Handling) in JSF2??
Actually the spec clearly states that all new features tagwise will be Facelets only since JSP is only seen as legacy technology. But that does not prevent anyone backporting those features if he/she is willing to do that :-) Werner Am 28.02.10 15:04, schrieb Jakob Korherr: Hi, The tag exists (and works) only if you're using facelets-2. It is no supported on JSP (like some other new features like e.g. f:ajax). Regards, Jakob 2010/2/28 Rudy De Busscher rdebussc...@gmail.com mailto:rdebussc...@gmail.com Hi, I saw on several places the mentioning of a Declarative Event Handling in JSF 2. But I couldn't find support for the f:event in Myfaces 2 beta. A quick look into Mojarra revealed that they also don't support the tag. Looking up the tag documentation shows a difference between the 2 sources . The VDL Tag Library Documentation for JSF (__https://javaserverfaces.dev.java.net/nonav/docs/2.0/pdldocs/facelets/index.html) doesn't have a mention of f:event but the VDL tag Library Documentation for facelets2 (https://javaserverfaces.dev.java.net/nonav/docs/2.0/pdldocs/jsp/index.html) has the tag listed. Is there a Declarative Event Handling in JSF 2 (and thus missing code) or not ?? Thx regards Rudy.
[GSOC] HTML5 Renderkit Start-up
Hi, I've started working on HTML5 renderkit, which I will apply GSOC this year. I haven't done much, just created the project, configured the builder (modified Tomahawk's building procedure). Now I am trying to determine what to implement and how people will use it after we are done. So I am writing some example component codes to get your ideas. The project is hosted on Google Code: http://code.google.com/p/myfaces-html5-starter/ I will appreciate some review on pages at: http://code.google.com/p/myfaces-html5-starter/source/browse/#svn/trunk/src/test/resources/tag-interface Please note that, components are not implemented yet. Code on xhtml pages are just trials. If anybody is interested, please feel free to send me your feedback :) Thanks, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
[jira] Updated: (TRINIDAD-1735) Trinidad 2: Provide ViewDeclarationLanguageFactory wrapper instead of overriding ViewHandler.getViewDeclarationLanguage()
[ https://issues.apache.org/jira/browse/TRINIDAD-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1735: -- Status: Patch Available (was: Open) Trinidad 2: Provide ViewDeclarationLanguageFactory wrapper instead of overriding ViewHandler.getViewDeclarationLanguage() - Key: TRINIDAD-1735 URL: https://issues.apache.org/jira/browse/TRINIDAD-1735 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.2-core Reporter: Max Starets Assignee: Max Starets Attachments: trinidad-1735.diff We override ViewHandler.getViewDeclarationLanguage() to return null VDL for the internal views and to call inro PageResolver before determining the VDL. The problem is our override does not get called during ViewHandler.createView() because the delegate ViewHandler just calls getViewDeclarationLanguage on itself. This is not causing any serious problems today because both Facelets and JSP VDLs call into the same base implementation of createView(). However, the right solution will be to stop overriding getViewDeclarationLanguage() on the ViewHandler and start wrapping ViewDeclarationLanguageFactory instead, so we can start overriding getViewDeclarationLanguage() there. According to JavaDoc, ViewHandler.getViewDeclarationLanguage() is merely a convenience method. As such it should have been made final in the JSF API, and problems like these would be easily prevented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1735) Trinidad 2: Provide ViewDeclarationLanguageFactory wrapper instead of overriding ViewHandler.getViewDeclarationLanguage()
[ https://issues.apache.org/jira/browse/TRINIDAD-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839848#action_12839848 ] Max Starets commented on TRINIDAD-1735: --- Changing the priority to Major, as it turns out that ViewHandler.renderView() does not call our override either. Since we have to make the ViewDeclarationLanguageFactory aware of the InternalViews, it makes sense to move all logic related to the InternalViews from ViewHandlerImpl to the new ViewDeclarationLanguageFactoryImpl. This will allow us to expose InternalView handling as a VDL, which is a cleaner solution consistent with the JSF 2 architecture. The only issue is that ViewDeclarationLanguage does not expose writeState(0, so we will have to leave a minimal amount of the InternalView-related code in the ViewHandlerImpl. Trinidad 2: Provide ViewDeclarationLanguageFactory wrapper instead of overriding ViewHandler.getViewDeclarationLanguage() - Key: TRINIDAD-1735 URL: https://issues.apache.org/jira/browse/TRINIDAD-1735 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.2-core Reporter: Max Starets Assignee: Max Starets Attachments: trinidad-1735.diff We override ViewHandler.getViewDeclarationLanguage() to return null VDL for the internal views and to call inro PageResolver before determining the VDL. The problem is our override does not get called during ViewHandler.createView() because the delegate ViewHandler just calls getViewDeclarationLanguage on itself. This is not causing any serious problems today because both Facelets and JSP VDLs call into the same base implementation of createView(). However, the right solution will be to stop overriding getViewDeclarationLanguage() on the ViewHandler and start wrapping ViewDeclarationLanguageFactory instead, so we can start overriding getViewDeclarationLanguage() there. According to JavaDoc, ViewHandler.getViewDeclarationLanguage() is merely a convenience method. As such it should have been made final in the JSF API, and problems like these would be easily prevented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Trinidad2] InternalView VDL/TRINIDAD-1735
Hello Everyone, While I was working on a solution for TRINIDAD-1735, I realized that the clean solution would involve moving all the code dealing with InternalViews from the ViewHandlerImpl to the new ViewDeclarationLanguageFactoryImpl. We also would expose a special VDL for the internal views, which is what Martin Koci suggested a while ago. Pleas review the jira and the associated patch. If there are no objections, I will commit the change in a few days. Thanks, Max
Re: [Trinidad2] InternalView VDL/TRINIDAD-1735
Will this affect the Controller team? Gary Kind Max Starets wrote: Hello Everyone, While I was working on a solution for TRINIDAD-1735, I realized that the clean solution would involve moving all the code dealing with InternalViews from the ViewHandlerImpl to the new ViewDeclarationLanguageFactoryImpl. We also would expose a special VDL for the internal views, which is what Martin Koci suggested a while ago. Pleas review the jira and the associated patch. If there are no objections, I will commit the change in a few days. Thanks, Max
Re: [Trinidad2] InternalView VDL/TRINIDAD-1735
Gary, No, this just sn internal reorganization, and there will be no API changes. Max On Mar 1, 2010, at 7:04 PM, Gary Kind gary.k...@oracle.com wrote: Will this affect the Controller team? Gary Kind Max Starets wrote: Hello Everyone, While I was working on a solution for TRINIDAD-1735, I realized that the clean solution would involve moving all the code dealing with InternalViews from the ViewHandlerImpl to the new ViewDeclarationLanguageFactoryImpl. We also would expose a special VDL for the internal views, which is what Martin Koci suggested a while ago. Pleas review the jira and the associated patch. If there are no objections, I will commit the change in a few days. Thanks, Max
Re: [Trinidad2] InternalView VDL/TRINIDAD-1735
-1 on the patch. We really can't use license header from LGPL2code...: -InternalViewHandlingStrategy -ViewDeclarationLanguageFactoryImpl Nor can't we copy code from the SUN RI to Apache. -Matthias On Tue, Mar 2, 2010 at 1:40 AM, Max Starets max.star...@oracle.com wrote: Gary, No, this just sn internal reorganization, and there will be no API changes. Max On Mar 1, 2010, at 7:04 PM, Gary Kind gary.k...@oracle.com wrote: Will this affect the Controller team? Gary Kind Max Starets wrote: Hello Everyone, While I was working on a solution for TRINIDAD-1735, I realized that the clean solution would involve moving all the code dealing with InternalViews from the ViewHandlerImpl to the new ViewDeclarationLanguageFactoryImpl. We also would expose a special VDL for the internal views, which is what Martin Koci suggested a while ago. Pleas review the jira and the associated patch. If there are no objections, I will commit the change in a few days. Thanks, Max -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad2] InternalView VDL/TRINIDAD-1735
here is some background on not allowed licenses: http://www.apache.org/legal/resolved.html#category-x -Matthias On Tue, Mar 2, 2010 at 7:19 AM, Matthias Wessendorf mat...@apache.org wrote: -1 on the patch. We really can't use license header from LGPL2code...: -InternalViewHandlingStrategy -ViewDeclarationLanguageFactoryImpl Nor can't we copy code from the SUN RI to Apache. -Matthias On Tue, Mar 2, 2010 at 1:40 AM, Max Starets max.star...@oracle.com wrote: Gary, No, this just sn internal reorganization, and there will be no API changes. Max On Mar 1, 2010, at 7:04 PM, Gary Kind gary.k...@oracle.com wrote: Will this affect the Controller team? Gary Kind Max Starets wrote: Hello Everyone, While I was working on a solution for TRINIDAD-1735, I realized that the clean solution would involve moving all the code dealing with InternalViews from the ViewHandlerImpl to the new ViewDeclarationLanguageFactoryImpl. We also would expose a special VDL for the internal views, which is what Martin Koci suggested a while ago. Pleas review the jira and the associated patch. If there are no objections, I will commit the change in a few days. Thanks, Max -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
