Re: [jira] Created: (MYFACES-1909) Implement JSF 2.0 Early Draf 2008-04-21
Great. Manfred/others, I think we should already create a component in JIRA for JSF.next -Matthias On Thu, Aug 28, 2008 at 12:31 AM, Simon Lessard (JIRA) dev@myfaces.apache.org wrote: Implement JSF 2.0 Early Draf 2008-04-21 --- Key: MYFACES-1909 URL: https://issues.apache.org/jira/browse/MYFACES-1909 Project: MyFaces Core Issue Type: Task Reporter: Simon Lessard Assignee: Simon Lessard Priority: Minor A JSF 2.0 branch was created at https://svn.apache.org/repos/asf/myfaces/core/branches/2_0_0. While there's no official release of the spec, I won't create a brand new category for this issue. My team and anyone else willing to help can attach the patches here. If it gets too tricky we might change the work flow and I'll have a JIRA component created specifically for JSR-314 where we can create as much ticket as needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Matthias Wessendorf Need JSF and Web 2.0? http://code.google.com/p/facesgoodies further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Created: (MYFACES-1910) Add resetValue() to EditableValueHolder interface (this is a JSF 2.0 related issue)
Add resetValue() to EditableValueHolder interface (this is a JSF 2.0 related issue) --- Key: MYFACES-1910 URL: https://issues.apache.org/jira/browse/MYFACES-1910 Project: MyFaces Core Issue Type: Improvement Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf In JSF 2.0, they finally improve the EditableValueHolder interface: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=438 fix is pretty simple. UIInput already provides the implementation. Just add the method to the interface -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
JSF2.0 implementation
I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. And with 3 branches to now maintain, we need to discuss whether and when we phase out maintenance of the jsf-1.1 branch. Currently when users provide patches in jira, they almost always provide a patch against only one version and the committer ports it, which does increase the load on existing committers. When do we stop asking committers to do this when patching bugs? To repeat, I'm *happy* that jsf2.0 implementation is in progress, and appreciate people contributing time to write an ASF-2.0-licensed implementation. But it is a standard saying at Apache that community is more important than code, and the community aspect here seems to have been rather neglected... Regards, Simon
Re: JSF2.0 implementation
Simon, You can do a search for Subject = '[OT] JSF 2.0' on the Dev list. I believe that discussion, begun by MW turned into a discussion about branch creation... then a couple of +1s followed and I assume that's where the branch was born. Cheers, Zubin. On 8/28/08, Simon Kitching [EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. And with 3 branches to now maintain, we need to discuss whether and when we phase out maintenance of the jsf-1.1 branch. Currently when users provide patches in jira, they almost always provide a patch against only one version and the committer ports it, which does increase the load on existing committers. When do we stop asking committers to do this when patching bugs? To repeat, I'm *happy* that jsf2.0 implementation is in progress, and appreciate people contributing time to write an ASF-2.0-licensed implementation. But it is a standard saying at Apache that community is more important than code, and the community aspect here seems to have been rather neglected... Regards, Simon
MyFaces Orchestra 1.2 Released
The Apache MyFaces Orchestra team is pleased to announce the release of Apache MyFaces Orchestra Core 1.2. Get a full overview at Orchestra's homepage [1]. The distribution is available at * http://myfaces.apache.org/orchestra/download.html Apache MyFaces Orchestra is available in the central Maven repository under Group ID org.apache.myfaces.orchestra. Have fun! Regards, Simon [1] http://myfaces.apache.org/orchestra
[jira] Resolved: (MYFACES-1910) Add resetValue() to EditableValueHolder interface (this is a JSF 2.0 related issue)
[ https://issues.apache.org/jira/browse/MYFACES-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved MYFACES-1910. - Resolution: Fixed Fix Version/s: 2.0.0-aplha implemented interface method. Added JavaDoc (taken from Trinidad) Add resetValue() to EditableValueHolder interface (this is a JSF 2.0 related issue) --- Key: MYFACES-1910 URL: https://issues.apache.org/jira/browse/MYFACES-1910 Project: MyFaces Core Issue Type: Improvement Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf Fix For: 2.0.0-alpha In JSF 2.0, they finally improve the EditableValueHolder interface: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=438 fix is pretty simple. UIInput already provides the implementation. Just add the method to the interface -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JSF2.0 implementation
On Thu, Aug 28, 2008 at 8:56 AM, Simon Kitching [EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. which is good. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. hrm, I was active on this thread: http://www.mail-archive.com/dev@myfaces.apache.org/msg32651.html One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. that is true, but I think we can live with it. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. Where did this code come from? Do we need a code grant for it? Note that when code he is part of the Trinidad project; And it was already mentioned that some offline developments are OK. Remember the discussion with Werner's dojo extensions for Tomahawk ? is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. in Werner's case it was not (at least that's what I remember from the discussion) And with 3 branches to now maintain, we need to discuss whether and when we phase out maintenance of the jsf-1.1 branch. Currently when users provide patches in jira, they almost always provide a patch against only one version and the committer ports it, which does increase the load on existing committers. When do we stop asking committers to do this when patching bugs? Why not putting JSF 1.1 to maintain stage; Do some more JSF 1.2 releases (like Leo is planing to do) and keep the JSF 2.0 active. even if we need to re-branch (or need to apply some other (plugin related) changes To repeat, I'm *happy* that jsf2.0 implementation is in progress, and appreciate people contributing time to write an ASF-2.0-licensed implementation. But it is a standard saying at Apache that community is more important than code, and the community aspect here seems to have been rather neglected... Ok, we did a small discussion on that. The code he added is listed in the JavaDoc, from the spec... I think we are fine here. -Matthias Regards, Simon -- Matthias Wessendorf Need JSF and Web 2.0? http://code.google.com/p/facesgoodies further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: JSF2.0 implementation
But that thread is from Jun 04 - that is very nearly 3 months ago. Since then, nothing as far as I know. Zubin Wadia schrieb: Simon, You can do a search for Subject = '[OT] JSF 2.0' on the Dev list. I believe that discussion, begun by MW turned into a discussion about branch creation... then a couple of +1s followed and I assume that's where the branch was born. Cheers, Zubin. On 8/28/08, *Simon Kitching* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. And with 3 branches to now maintain, we need to discuss whether and when we phase out maintenance of the jsf-1.1 branch. Currently when users provide patches in jira, they almost always provide a patch against only one version and the committer ports it, which does increase the load on existing committers. When do we stop asking committers to do this when patching bugs? To repeat, I'm *happy* that jsf2.0 implementation is in progress, and appreciate people contributing time to write an ASF-2.0-licensed implementation. But it is a standard saying at Apache that community is more important than code, and the community aspect here seems to have been rather neglected... Regards, Simon
Re: JSF2.0 implementation
On Thu, Aug 28, 2008 at 9:00 AM, Zubin Wadia [EMAIL PROTECTED] wrote: Simon, You can do a search for Subject = '[OT] JSF 2.0' on the Dev list. I believe that discussion, begun by MW turned into a discussion about branch creation... then a couple of +1s followed and I assume that's where the branch was born. correct. Also, it has happened quite some times that some code was just committed (or close to be) -Orchestra (aka Fusion) -Dojo-extensions, from Werner (are they already in?) If you feel uncomfortable, please do a revert. -Matthias Cheers, Zubin. On 8/28/08, Simon Kitching [EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. And with 3 branches to now maintain, we need to discuss whether and when we phase out maintenance of the jsf-1.1 branch. Currently when users provide patches in jira, they almost always provide a patch against only one version and the committer ports it, which does increase the load on existing committers. When do we stop asking committers to do this when patching bugs? To repeat, I'm *happy* that jsf2.0 implementation is in progress, and appreciate people contributing time to write an ASF-2.0-licensed implementation. But it is a standard saying at Apache that community is more important than code, and the community aspect here seems to have been rather neglected... Regards, Simon -- Matthias Wessendorf Need JSF and Web 2.0? http://code.google.com/p/facesgoodies further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: JSF2.0 implementation
On Thu, Aug 28, 2008 at 9:10 AM, Simon Kitching [EMAIL PROTECTED] wrote: But that thread is from Jun 04 - that is very nearly 3 months ago. Since then, nothing as far as I know. ok, perhaps just a hello, I have done some development on my machine, is the myfaces community still willing to provide a JSF 2.0 implementation. That would have been enough, IMO. -Matthias Zubin Wadia schrieb: Simon, You can do a search for Subject = '[OT] JSF 2.0' on the Dev list. I believe that discussion, begun by MW turned into a discussion about branch creation... then a couple of +1s followed and I assume that's where the branch was born. Cheers, Zubin. On 8/28/08, *Simon Kitching* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. And with 3 branches to now maintain, we need to discuss whether and when we phase out maintenance of the jsf-1.1 branch. Currently when users provide patches in jira, they almost always provide a patch against only one version and the committer ports it, which does increase the load on existing committers. When do we stop asking committers to do this when patching bugs? To repeat, I'm *happy* that jsf2.0 implementation is in progress, and appreciate people contributing time to write an ASF-2.0-licensed implementation. But it is a standard saying at Apache that community is more important than code, and the community aspect here seems to have been rather neglected... Regards, Simon -- Matthias Wessendorf Need JSF and Web 2.0? http://code.google.com/p/facesgoodies further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Commented: (TRINIDAD-1195) Length validator broken if maximum attributes is missing
[ https://issues.apache.org/jira/browse/TRINIDAD-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626468#action_12626468 ] Stephen Friedrich commented on TRINIDAD-1195: - Thanks Matthias for caring about this. I'm sorry to say that the strange error message (don't enter fewer than 0 characters) when using server side validation has _not_ been fixed in the current svn version. Also, I checked the PPR bugs in TRINIDAD-1130 (marked as fixed in 1.2.9): Those bugs are also still happening in latest svn. Length validator broken if maximum attributes is missing -- Key: TRINIDAD-1195 URL: https://issues.apache.org/jira/browse/TRINIDAD-1195 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.9-core Reporter: Stephen Friedrich Assignee: Matthias Weßendorf Fix For: 1.2.10-core, 1.0.10-core Attachments: 0-or-more-not-fewer.png, 2-up-to-a-maximum-of-0.png, confused.PNG tr:validateLength minimum=2 Client side validation _always_ results in Enter 2 or more characters, up to a maximum of 0. No valid data can be entered at all. Server side validation works in principal, but spits out an incorrect message when the validation (correctly) fails: Enter 0 or more characters, not fewer. See https://issues.apache.org/jira/browse/TRINIDAD-1130 for test.war that you can simply drop into Tomcat 6. Much of my code omits the maximum attribute, because I have a maximum length set on my input components (so that joe user just cannot enter more characters anyway) and have wrapped the form in a seam validation (s:validateAll) that validates on the server side against constraints set with hibernate validation annotations on the entity objects (so that a hacker can do no harm). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1195) Length validator broken if maximum attributes is missing
[ https://issues.apache.org/jira/browse/TRINIDAD-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626475#action_12626475 ] Matthias Weßendorf commented on TRINIDAD-1195: -- Bug: Field is always required, even when set to false via PPR. = I noticed it has changed (the required is removed, when clicking the checkbox) Bug: inputText looses its value when switching from disabled to not-disabled. I saw as well. Can you please keep these bugs separate ? It is pretty confusing to discuss several (not related) things in one bug ? Regarding: Bug: inputText looses its value when switching from disabled to not-disabled. Can you open a ticket ? Length validator broken if maximum attributes is missing -- Key: TRINIDAD-1195 URL: https://issues.apache.org/jira/browse/TRINIDAD-1195 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.9-core Reporter: Stephen Friedrich Assignee: Matthias Weßendorf Fix For: 1.2.10-core, 1.0.10-core Attachments: 0-or-more-not-fewer.png, 2-up-to-a-maximum-of-0.png, confused.PNG, server-side1.PNG, server-side2.PNG tr:validateLength minimum=2 Client side validation _always_ results in Enter 2 or more characters, up to a maximum of 0. No valid data can be entered at all. Server side validation works in principal, but spits out an incorrect message when the validation (correctly) fails: Enter 0 or more characters, not fewer. See https://issues.apache.org/jira/browse/TRINIDAD-1130 for test.war that you can simply drop into Tomcat 6. Much of my code omits the maximum attribute, because I have a maximum length set on my input components (so that joe user just cannot enter more characters anyway) and have wrapped the form in a seam validation (s:validateAll) that validates on the server side against constraints set with hibernate validation annotations on the entity objects (so that a hacker can do no harm). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-205) Need to avoid IE's number of CSS selectors limitation
[
https://issues.apache.org/jira/browse/TRINIDAD-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626477#action_12626477
]
Matthias Weßendorf commented on TRINIDAD-205:
-
from jeanne (on the ML)
It is acceptable to me. Perhaps you can create a JIRA for these kinds of
cleanups (and/or add a TODO to the code). This Skinning code has been around
and added to for many years, and could use a cleanup. I definitely agree with
the StyleContext and StyleProvider being linked. That is really confusing.
Need to avoid IE's number of CSS selectors limitation
-
Key: TRINIDAD-205
URL: https://issues.apache.org/jira/browse/TRINIDAD-205
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.0.1-incubating-core-SNAPSHOT
Reporter: Jeanne Waldman
Assignee: Simon Lessard
Attachments: TRINIDAD-205.patch
it turns out that IE has a limit to the size of a CSS file. It's not the
actual size of the file, but rather it is the
# of CSS selectors. I did a test and found out that the limit is 4095 CSS
selectors.
Firefox doesn't appear to have a limit.
As you may know, the CSS file we generate contains both compressed and
uncompressed styles, like this:
.af_inputText_content, .x01 {background-color: blue}
Our renderers render a shortened styleclass, unless
the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml, then it
renders the long styleclass.
input class=x01...
Ok, that's the background.
*The problem* is that because we have a lot of custom components that we've
built on top of Trinidad, and our customers
have built custom components, etc, and these all have skinning,
we have bumped up against the 4095 selector limit in IE. All selectors after
the 4095th one are ignored.
*A quick fix*, and probably a good one for a long time, is to render the
styles in compressed mode when compression is on,
or in uncompressed mode when compression if off. That will reduce our style
selectors by 1/2, and will help performance to boot. :)
I can also add a warning if we go past 4095 selectors for IE.
Another solution is to break up the file into multiple files when I've
reached the limit in one file, and include
all the css files into the rendered page. I can do this in addition to the
quick fix when I have more time.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1195) Length validator broken if maximum attributes is missing
[ https://issues.apache.org/jira/browse/TRINIDAD-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626480#action_12626480 ] Stephen Friedrich commented on TRINIDAD-1195: - entered 1 and got an error (as expected) Yes, but please do have a close look at the screenshot server-side1.PNG you uploaded yourself. It shows exactly the problem that I mentioned right from the start: Server side validation works in principal, but spits out an incorrect message when the validation (correctly) fails: Enter 0 or more characters, not fewer. You might just as well call that message funny or stupid, but it will definitely confuse users when they are told not to enter fewer than zero characters. I noticed it has changed (the required is removed, when clicking the checkbox) Yes, the icon is removed, but _try to submit_ with an empty value and validation fails and tells you you must enter a value. Length validator broken if maximum attributes is missing -- Key: TRINIDAD-1195 URL: https://issues.apache.org/jira/browse/TRINIDAD-1195 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.9-core Reporter: Stephen Friedrich Assignee: Matthias Weßendorf Fix For: 1.2.10-core, 1.0.10-core Attachments: 0-or-more-not-fewer.png, 2-up-to-a-maximum-of-0.png, confused.PNG, server-side1.PNG, server-side2.PNG tr:validateLength minimum=2 Client side validation _always_ results in Enter 2 or more characters, up to a maximum of 0. No valid data can be entered at all. Server side validation works in principal, but spits out an incorrect message when the validation (correctly) fails: Enter 0 or more characters, not fewer. See https://issues.apache.org/jira/browse/TRINIDAD-1130 for test.war that you can simply drop into Tomcat 6. Much of my code omits the maximum attribute, because I have a maximum length set on my input components (so that joe user just cannot enter more characters anyway) and have wrapped the form in a seam validation (s:validateAll) that validates on the server side against constraints set with hibernate validation annotations on the entity objects (so that a hacker can do no harm). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release of myfaces core 1.2.4
+1 On Wed, Aug 27, 2008 at 8:51 PM, Cagatay Civici [EMAIL PROTECTED] wrote: +1 On Wed, Aug 27, 2008 at 9:43 PM, Bruno Aranda [EMAIL PROTECTED] wrote: +1 2008/8/27 Grant Smith [EMAIL PROTECTED] +0 sorry I'm swamped. Good job on the TCK. On 8/27/08, Hazem Saleh [EMAIL PROTECTED] wrote: +1, Thanks Leonardo. On Wed, Aug 27, 2008 at 9:08 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: On Wed, Aug 27, 2008 at 1:07 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.2.4 release of Apache MyFaces core out. The artifacts passed all TCK test. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v3.0.4 [1] 2. Maven artifact group org.apache.myfaces.core v1.2.4 [1] The artifacts are deployed to my private Apache account ([1] and [3] for binary and source packages). The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 1.2.4 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +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, Leonardo Uribe [1] http://people.apache.org/~lu4242/myfaces124 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces124binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12313378 +1 regards Leonardo Uribe -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog GMaps Integration with JSF: http://code.google.com/p/gmaps4jsf/ -- Grant Smith -- Matthias Wessendorf Need JSF and Web 2.0? http://code.google.com/p/facesgoodies further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Created: (TRINIDAD-1198) inputText looses its values when switched from disabled to enabled using PPR
inputText looses its values when switched from disabled to enabled using PPR Key: TRINIDAD-1198 URL: https://issues.apache.org/jira/browse/TRINIDAD-1198 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Reporter: Stephen Friedrich Title says it all: When a disabled text field contains some text, then some PPR action sets disabled=false on that field, then the field losses its value. All text is gone. See TRINIDAD-1130 for an example app (the bug also still occurs with current svn version). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1195) Length validator broken if maximum attributes is missing
[ https://issues.apache.org/jira/browse/TRINIDAD-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626483#action_12626483 ] Matthias Weßendorf commented on TRINIDAD-1195: -- Stephen, I am sorry. I found the issue. We pass the MAX into the message I am sorry, I haven't watched the pic close enough. regarding the other issues, can you open separate bugs on that? Length validator broken if maximum attributes is missing -- Key: TRINIDAD-1195 URL: https://issues.apache.org/jira/browse/TRINIDAD-1195 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.9-core Reporter: Stephen Friedrich Assignee: Matthias Weßendorf Fix For: 1.2.10-core, 1.0.10-core Attachments: 0-or-more-not-fewer.png, 2-up-to-a-maximum-of-0.png, confused.PNG, server-side1.PNG, server-side2.PNG tr:validateLength minimum=2 Client side validation _always_ results in Enter 2 or more characters, up to a maximum of 0. No valid data can be entered at all. Server side validation works in principal, but spits out an incorrect message when the validation (correctly) fails: Enter 0 or more characters, not fewer. See https://issues.apache.org/jira/browse/TRINIDAD-1130 for test.war that you can simply drop into Tomcat 6. Much of my code omits the maximum attribute, because I have a maximum length set on my input components (so that joe user just cannot enter more characters anyway) and have wrapped the form in a seam validation (s:validateAll) that validates on the server side against constraints set with hibernate validation annotations on the entity objects (so that a hacker can do no harm). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1199) Field is always required, even when set to false via PPR
Field is always required, even when set to false via PPR Key: TRINIDAD-1199 URL: https://issues.apache.org/jira/browse/TRINIDAD-1199 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Reporter: Stephen Friedrich When a tr:inputText is switched from required=true to required=false using PPR, then the required icon is correctly removed, but validation still fails if the inputText is empty. See TRINIDAD-1130 for an example app. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1195) Length validator broken if maximum attributes is missing
[ https://issues.apache.org/jira/browse/TRINIDAD-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626484#action_12626484 ] Stephen Friedrich commented on TRINIDAD-1195: - Thanks Matthias, I created TRINIDAD-1198 and TRINIDAD-1199 for the PPR problems, so we can continue any necessary discussion there. Length validator broken if maximum attributes is missing -- Key: TRINIDAD-1195 URL: https://issues.apache.org/jira/browse/TRINIDAD-1195 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.9-core Reporter: Stephen Friedrich Assignee: Matthias Weßendorf Fix For: 1.2.10-core, 1.0.10-core Attachments: 0-or-more-not-fewer.png, 2-up-to-a-maximum-of-0.png, confused.PNG, server-side1.PNG, server-side2.PNG tr:validateLength minimum=2 Client side validation _always_ results in Enter 2 or more characters, up to a maximum of 0. No valid data can be entered at all. Server side validation works in principal, but spits out an incorrect message when the validation (correctly) fails: Enter 0 or more characters, not fewer. See https://issues.apache.org/jira/browse/TRINIDAD-1130 for test.war that you can simply drop into Tomcat 6. Much of my code omits the maximum attribute, because I have a maximum length set on my input components (so that joe user just cannot enter more characters anyway) and have wrapped the form in a seam validation (s:validateAll) that validates on the server side against constraints set with hibernate validation annotations on the entity objects (so that a hacker can do no harm). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1198) inputText looses its values when switched from disabled to enabled using PPR
[ https://issues.apache.org/jira/browse/TRINIDAD-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626486#action_12626486 ] Matthias Weßendorf commented on TRINIDAD-1198: -- immediate=true I see on the selectBooleanCheckbox ... inputText looses its values when switched from disabled to enabled using PPR Key: TRINIDAD-1198 URL: https://issues.apache.org/jira/browse/TRINIDAD-1198 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Reporter: Stephen Friedrich Title says it all: When a disabled text field contains some text, then some PPR action sets disabled=false on that field, then the field losses its value. All text is gone. See TRINIDAD-1130 for an example app (the bug also still occurs with current svn version). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1199) Field is always required, even when set to false via PPR
[ https://issues.apache.org/jira/browse/TRINIDAD-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626488#action_12626488 ] Matthias Weßendorf commented on TRINIDAD-1199: -- I don't see the validation error -unchecked isInternal = Contract Vacation Days become not required (and disabled) -clicking SAVE works fine. also, when I remove the disabled flag (so the field is editable), I don't get any warnings (when the field is not required) tested w/ 1.2.10 and server-side validation OFF and! ON. Help me to understand the problem Field is always required, even when set to false via PPR Key: TRINIDAD-1199 URL: https://issues.apache.org/jira/browse/TRINIDAD-1199 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Reporter: Stephen Friedrich When a tr:inputText is switched from required=true to required=false using PPR, then the required icon is correctly removed, but validation still fails if the inputText is empty. See TRINIDAD-1130 for an example app. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1198) inputText looses its values when switched from disabled to enabled using PPR
[ https://issues.apache.org/jira/browse/TRINIDAD-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626490#action_12626490 ] Stephen Friedrich commented on TRINIDAD-1198: - So? The valueChangeListener of the selectBooleanCheckbox shortens the jsf lifecycle by calling FacesContext.getCurrentInstance().renderResponse(); so in any case the inputText's value should be unaffected, right? (And in fact it works fine when switching from enabled to disabled.) inputText looses its values when switched from disabled to enabled using PPR Key: TRINIDAD-1198 URL: https://issues.apache.org/jira/browse/TRINIDAD-1198 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Reporter: Stephen Friedrich Title says it all: When a disabled text field contains some text, then some PPR action sets disabled=false on that field, then the field losses its value. All text is gone. See TRINIDAD-1130 for an example app (the bug also still occurs with current svn version). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1198) inputText looses its values when switched from disabled to enabled using PPR
[ https://issues.apache.org/jira/browse/TRINIDAD-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626495#action_12626495 ] Stephen Friedrich commented on TRINIDAD-1198: - Ah, sorry, JSF is in fact tricky. Exactly because the input fields value is not processed it stays empty on the backing bean. Now when the inputText is told to refresh (partialTriggers) of course it comes back with that empty value. Hm, even though this is not a Trinidad bug, it is very unfortunate for the user. Do you have any idea for a workaround (i.e. refreshing only the disabled attribute, but not the value itself)? inputText looses its values when switched from disabled to enabled using PPR Key: TRINIDAD-1198 URL: https://issues.apache.org/jira/browse/TRINIDAD-1198 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Reporter: Stephen Friedrich Title says it all: When a disabled text field contains some text, then some PPR action sets disabled=false on that field, then the field losses its value. All text is gone. See TRINIDAD-1130 for an example app (the bug also still occurs with current svn version). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1200) inputFile upload problem
[ https://issues.apache.org/jira/browse/TRINIDAD-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626512#action_12626512 ] Tomas Havelka commented on TRINIDAD-1200: - I've tried to upload PDF file of 4,5m size with default file upload configuration (no memory nor disk space sizes configured). inputFile upload problem Key: TRINIDAD-1200 URL: https://issues.apache.org/jira/browse/TRINIDAD-1200 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.0.9-core Environment: Facelets, Spring, Orchestra Reporter: Tomas Havelka When trying to upload file, EOFException occurs and is logged to server log. But, as described in issue trinidad-607, I never got the ErrorFile with this error nor any FacesMessage is added for inputFile component. Just simple error is logged and page is refreshed. Try bigger file with your Demo, it does not work either. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1200) inputFile upload problem
[ https://issues.apache.org/jira/browse/TRINIDAD-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved TRINIDAD-1200. -- Resolution: Duplicate see TRINIDAD-1169 inputFile upload problem Key: TRINIDAD-1200 URL: https://issues.apache.org/jira/browse/TRINIDAD-1200 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.0.9-core Environment: Facelets, Spring, Orchestra Reporter: Tomas Havelka When trying to upload file, EOFException occurs and is logged to server log. But, as described in issue trinidad-607, I never got the ErrorFile with this error nor any FacesMessage is added for inputFile component. Just simple error is logged and page is refreshed. Try bigger file with your Demo, it does not work either. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1169) inputfile: no feedback when file is too big (like 30mb)
[ https://issues.apache.org/jira/browse/TRINIDAD-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626516#action_12626516 ] Tomas Havelka commented on TRINIDAD-1169: - Well, what is the work around to solve problem with uploading files bigger than 3m? inputfile: no feedback when file is too big (like 30mb) --- Key: TRINIDAD-1169 URL: https://issues.apache.org/jira/browse/TRINIDAD-1169 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.8-core, 1.2.8-core Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf Fix For: 1.2.10-core, 1.0.10-core Trinidad has an upload restriction. Default is ~2 MB I see the error message correctly for a 5MB file but not for a 30MB file. This should work for any size Stack in the wrong scenario is: java.io.EOFException: Per-request disk space limits exceeded. at org.apache.myfaces.trinidadinternal.config.upload.UploadedFileImpl.loadFile(UploadedFileImpl.java:242) at org.apache.myfaces.trinidadinternal.config.upload.UploadedFileProcessorImpl.processFile(UploadedFileProcessorImpl.java:129) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl._doUploadFile(FileUploadConfiguratorImpl.java:193) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:143) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:469) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:206) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:124) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450) 01.08.2008 12:09:32 org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl beginRequest SCHWERWIEGEND: java.lang.IllegalArgumentException at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler$Disposition.init(MultipartFormHandler.java:811) at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.getNextPart(MultipartFormHandler.java:188) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:118) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:469) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:206) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:124) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at
[jira] Commented: (TRINIDAD-1169) inputfile: no feedback when file is too big (like 30mb)
[ https://issues.apache.org/jira/browse/TRINIDAD-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626517#action_12626517 ] Matthias Weßendorf commented on TRINIDAD-1169: -- waiting for the .10 release or use a nightly (or patch your trinidad version) the fix is here: https://issues.apache.org/jira/browse/TRINIDAD-1169?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel inputfile: no feedback when file is too big (like 30mb) --- Key: TRINIDAD-1169 URL: https://issues.apache.org/jira/browse/TRINIDAD-1169 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.8-core, 1.2.8-core Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf Fix For: 1.2.10-core, 1.0.10-core Trinidad has an upload restriction. Default is ~2 MB I see the error message correctly for a 5MB file but not for a 30MB file. This should work for any size Stack in the wrong scenario is: java.io.EOFException: Per-request disk space limits exceeded. at org.apache.myfaces.trinidadinternal.config.upload.UploadedFileImpl.loadFile(UploadedFileImpl.java:242) at org.apache.myfaces.trinidadinternal.config.upload.UploadedFileProcessorImpl.processFile(UploadedFileProcessorImpl.java:129) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl._doUploadFile(FileUploadConfiguratorImpl.java:193) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:143) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:469) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:206) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:124) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450) 01.08.2008 12:09:32 org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl beginRequest SCHWERWIEGEND: java.lang.IllegalArgumentException at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler$Disposition.init(MultipartFormHandler.java:811) at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.getNextPart(MultipartFormHandler.java:188) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:118) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:469) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:206) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:124) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at
Re: [VOTE] release of myfaces core 1.2.4
+0 thanks Leonardo! --Manfred On Wed, Aug 27, 2008 at 8:07 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.2.4 release of Apache MyFaces core out. The artifacts passed all TCK test. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v3.0.4 [1] 2. Maven artifact group org.apache.myfaces.core v1.2.4 [1] The artifacts are deployed to my private Apache account ([1] and [3] for binary and source packages). The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 1.2.4 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +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, Leonardo Uribe [1] http://people.apache.org/~lu4242/myfaces124 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces124binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12313378 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (TRINIDAD-205) Need to avoid IE's number of CSS selectors limitation
[
https://issues.apache.org/jira/browse/TRINIDAD-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626560#action_12626560
]
Simon Lessard commented on TRINIDAD-205:
Sounds good to me. Thanks.
Need to avoid IE's number of CSS selectors limitation
-
Key: TRINIDAD-205
URL: https://issues.apache.org/jira/browse/TRINIDAD-205
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.0.1-incubating-core-SNAPSHOT
Reporter: Jeanne Waldman
Assignee: Simon Lessard
Attachments: TRINIDAD-205.patch
it turns out that IE has a limit to the size of a CSS file. It's not the
actual size of the file, but rather it is the
# of CSS selectors. I did a test and found out that the limit is 4095 CSS
selectors.
Firefox doesn't appear to have a limit.
As you may know, the CSS file we generate contains both compressed and
uncompressed styles, like this:
.af_inputText_content, .x01 {background-color: blue}
Our renderers render a shortened styleclass, unless
the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml, then it
renders the long styleclass.
input class=x01...
Ok, that's the background.
*The problem* is that because we have a lot of custom components that we've
built on top of Trinidad, and our customers
have built custom components, etc, and these all have skinning,
we have bumped up against the 4095 selector limit in IE. All selectors after
the 4095th one are ignored.
*A quick fix*, and probably a good one for a long time, is to render the
styles in compressed mode when compression is on,
or in uncompressed mode when compression if off. That will reduce our style
selectors by 1/2, and will help performance to boot. :)
I can also add a warning if we go past 4095 selectors for IE.
Another solution is to break up the file into multiple files when I've
reached the limit in one file, and include
all the css files into the rendered page. I can do this in addition to the
quick fix when I have more time.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1201) Cleanup the skinning code
Cleanup the skinning code - Key: TRINIDAD-1201 URL: https://issues.apache.org/jira/browse/TRINIDAD-1201 Project: MyFaces Trinidad Issue Type: Task Components: Skinning Affects Versions: 1.2.10-core, 1.0.10-core Reporter: Simon Lessard Priority: Minor Trinidad's skinning engine has been around for very long (UIX). Over the time, as features were added, the code, as it's often the case, got a little bit bloated and hard to understand. Some cleanup could definitely help on that. The main issue is the interdependency between StyleContext and StyleProvider, but it's not the only one. There's also the way selector limit is handled that I currently added. While it work, as mentioned in the JIRA ticket https://issues.apache.org/jira/browse/TRINIDAD-205 for some comment references, some form of interface would be much cleaner to make most methods Agent agnostic. One way I thought of would be to add something like a getStyleSheetWriter to StyleProvider that would return a writer able to create files as needed when the current agent suffers from a selector limitation (only IE to my knowledge) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JSF2.0 implementation
Hi Simon, On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching [EMAIL PROTECTED]wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. As mentioned by other people, there was a vote about this a while back . Why did I create it just now? Simply because my company agreed to provide some resource to help with the implementation and we were ready to get started. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. To be honest, I find this irrelevant, it's a branch, not a trunk and I'll most likely do some branch merging when core 1.2.x get release and the plugin might have to change a little to support jsfVersion 2.0. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. I see even less relevance in that statement. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. The code was coded just yesterday by me and is not much at all, creating missing classes for the JavaDoc change log is in no matter a large amount in term of complexity. Also since I was the only author of it (my teammates will wait until I have added the signatures). There's absolutely no need of code grant either. And with 3 branches to now maintain, we need to discuss whether and when we phase out maintenance of the jsf-1.1 branch. Currently when users provide patches in jira, they almost always provide a patch against only one version and the committer ports it, which does increase the load on existing committers. When do we stop asking committers to do this when patching bugs? I can take care of the branch merging, this is how we handled the trinidad 1.2 branch at first, Adam would do the merging every now and then, so I'm not asking the committers to do some extra work. To repeat, I'm *happy* that jsf2.0 implementation is in progress, and appreciate people contributing time to write an ASF-2.0-licensed implementation. But it is a standard saying at Apache that community is more important than code, and the community aspect here seems to have been rather neglected... I don't agree at all here. Although it wasn't announced on the dev list, the JIRA ticket created to attach patches was speciafically for the community. Code provided by Fujitsu employees will never go through me with direct commit, it will all be added as patches, even extra tests and documentation as we want them and everyone else willing to help get the credit for it. Furthermore, I personally didn't announce it because the branch will be very instable for a week or two until we finish adding the missing signatures (impl might not even always compile). If community wasn't important in the process we would just have used a private repository at Fujitsu, worked on it for some time with my team, then commit some very large amount of code (real large) that would have needed a code grant, prevented the people to see at what rythm things were progressing and contributing. The only point I *could* give you here is that maybe I should have annouced the creation directly on the dev list and point on the JIRA ticket and SVN url rather than relying only on JIRA ticket report that get forwarded on the dev list. Regards, ~ Simon Regards, Simon
[jira] Commented: (TRINIDAD-1169) inputfile: no feedback when file is too big (like 30mb)
[ https://issues.apache.org/jira/browse/TRINIDAD-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626595#action_12626595 ] Tomas Havelka commented on TRINIDAD-1169: - Fine. Now I got another error when trying to upload bigger file (with 1.0.10-SNAPSHOT): 500 Internal Server Error java.io.NotSerializableException: org.apache.myfaces.trinidadinternal.config.upload.ErrorFile at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1251) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1251) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1251) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) at org.apache.myfaces.trinidad.component.TreeState.writeExternal(TreeState.java:240) at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1310) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1288) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1251) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) at org.apache.myfaces.trinidad.component.TreeState.writeExternal(TreeState.java:241) at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1310) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1288) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1251) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) at org.apache.myfaces.trinidad.component.TreeState.writeExternal(TreeState.java:241) at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1310) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1288) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1251) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) at org.apache.myfaces.trinidad.component.TreeState.writeExternal(TreeState.java:241) at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1310) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1288) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1251) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) at org.apache.myfaces.trinidad.component.TreeState.writeExternal(TreeState.java:241) at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1310) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1288) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1251) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) at org.apache.myfaces.trinidad.component.TreeState.writeExternal(TreeState.java:241) at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1310) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1288) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1251) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) at org.apache.myfaces.trinidad.component.TreeState.writeExternal(TreeState.java:241) at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1310) at
Re: JSF2.0 implementation
On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Simon, On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching [EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. As mentioned by other people, there was a vote about this a while back . Why did I create it just now? Simply because my company agreed to provide some resource to help with the implementation and we were ready to get started. One might ask here for a CCLA ;-) We did that for Oracle way back, and update once in a while all the contributors, that have signed the iCLA. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. To be honest, I find this irrelevant, it's a branch, not a trunk and I'll most likely do some branch merging when core 1.2.x get release and the plugin might have to change a little to support jsfVersion 2.0. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. I see even less relevance in that statement. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. The code was coded just yesterday by me and is not much at all, creating missing classes for the JavaDoc change log is in no matter a large amount in term of complexity. Also since I was the only author of it (my teammates will wait until I have added the signatures). There's absolutely no need of code grant either. I agree on the code grant, b/c of it is really pretty trivial to create those API classes/interfaces (based on the javadoc log, as I said before). @signatures: you mean the iCLA / CCLA, aren't you ? And with 3 branches to now maintain, we need to discuss whether and when we phase out maintenance of the jsf-1.1 branch. Currently when users provide patches in jira, they almost always provide a patch against only one version and the committer ports it, which does increase the load on existing committers. When do we stop asking committers to do this when patching bugs? I can take care of the branch merging, this is how we handled the trinidad 1.2 branch at first, Adam would do the merging every now and then, so I'm not asking the committers to do some extra work. yup. not a big deal. Also I doubt that that many folks will work there, on the branch. If the branch needs some merging... fine as well, IMO. To repeat, I'm *happy* that jsf2.0 implementation is in progress, and appreciate people contributing time to write an ASF-2.0-licensed implementation. But it is a standard saying at Apache that community is more important than code, and the community aspect here seems to have been rather neglected... I don't agree at all here. Although it wasn't announced on the dev list, the JIRA ticket created to attach patches was speciafically for the community. and the branch creation was also discussed. Code provided by Fujitsu employees will never go through me with direct commit, it will all be added as patches, even extra tests and documentation as we want them and everyone else willing to help get the credit for it. we do the same. Folks provide patches and jira tickets to describe the problem. Furthermore, I personally didn't announce it because the branch will be very instable for a week or two until we finish adding the missing signatures (impl might not even always compile). dev@ is a developers community; so that would be fine :-) -Matthias If community wasn't important in the process we would just have used a private repository at Fujitsu, worked on it for some time with my team, then commit some very large amount of code (real large) that would have needed a code grant, prevented the people to see at what rythm things were progressing and contributing. The only point I *could* give you here is that maybe I should have annouced the creation directly on the dev list and point on the JIRA ticket and SVN url rather than relying only on JIRA ticket report that get forwarded on the dev list. Regards, ~ Simon Regards, Simon -- Matthias Wessendorf Need JSF and Web 2.0? http://code.google.com/p/facesgoodies further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Commented: (TRINIDAD-1169) inputfile: no feedback when file is too big (like 30mb)
[ https://issues.apache.org/jira/browse/TRINIDAD-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626596#action_12626596 ] Matthias Weßendorf commented on TRINIDAD-1169: -- ok, update the Error to impl. the interface; change is on the way :) inputfile: no feedback when file is too big (like 30mb) --- Key: TRINIDAD-1169 URL: https://issues.apache.org/jira/browse/TRINIDAD-1169 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.8-core, 1.2.8-core Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf Fix For: 1.2.10-core, 1.0.10-core Trinidad has an upload restriction. Default is ~2 MB I see the error message correctly for a 5MB file but not for a 30MB file. This should work for any size Stack in the wrong scenario is: java.io.EOFException: Per-request disk space limits exceeded. at org.apache.myfaces.trinidadinternal.config.upload.UploadedFileImpl.loadFile(UploadedFileImpl.java:242) at org.apache.myfaces.trinidadinternal.config.upload.UploadedFileProcessorImpl.processFile(UploadedFileProcessorImpl.java:129) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl._doUploadFile(FileUploadConfiguratorImpl.java:193) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:143) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:469) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:206) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:124) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450) 01.08.2008 12:09:32 org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl beginRequest SCHWERWIEGEND: java.lang.IllegalArgumentException at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler$Disposition.init(MultipartFormHandler.java:811) at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.getNextPart(MultipartFormHandler.java:188) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:118) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:469) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:206) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:124) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at
Re: JSF2.0 implementation
On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf [EMAIL PROTECTED]wrote: On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Simon, On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching [EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. As mentioned by other people, there was a vote about this a while back . Why did I create it just now? Simply because my company agreed to provide some resource to help with the implementation and we were ready to get started. One might ask here for a CCLA ;-) We did that for Oracle way back, and update once in a while all the contributors, that have signed the iCLA. Yeah, but Fujistu signed a CCLA already when I became commiter, so that's a non issue as well. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. To be honest, I find this irrelevant, it's a branch, not a trunk and I'll most likely do some branch merging when core 1.2.x get release and the plugin might have to change a little to support jsfVersion 2.0. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. I see even less relevance in that statement. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. The code was coded just yesterday by me and is not much at all, creating missing classes for the JavaDoc change log is in no matter a large amount in term of complexity. Also since I was the only author of it (my teammates will wait until I have added the signatures). There's absolutely no need of code grant either. I agree on the code grant, b/c of it is really pretty trivial to create those API classes/interfaces (based on the javadoc log, as I said before). @signatures: you mean the iCLA / CCLA, aren't you ? nah, I meant method signatures, it will be easier for my teammates to know what they have to do once there's a nice // TODO: Convert to JSF 2.0 added in every new method's body. As far as I understand the legal issues (might have to fallback to [EMAIL PROTECTED] though), they won't need a CLA until they become commiters. I don't know if I should have the company add their names to the CCLA however. Technically, we aren't bound contractualy by any intellectual property transfer with my employer and we're developping outside normal business hours so we aren't directly paid either for it so I don't know if adding their name to the CCLA is even needed or not. ~ Simon And with 3 branches to now maintain, we need to discuss whether and when we phase out maintenance of the jsf-1.1 branch. Currently when users provide patches in jira, they almost always provide a patch against only one version and the committer ports it, which does increase the load on existing committers. When do we stop asking committers to do this when patching bugs? I can take care of the branch merging, this is how we handled the trinidad 1.2 branch at first, Adam would do the merging every now and then, so I'm not asking the committers to do some extra work. yup. not a big deal. Also I doubt that that many folks will work there, on the branch. If the branch needs some merging... fine as well, IMO. To repeat, I'm *happy* that jsf2.0 implementation is in progress, and appreciate people contributing time to write an ASF-2.0-licensed implementation. But it is a standard saying at Apache that community is more important than code, and the community aspect here seems to have been rather neglected... I don't agree at all here. Although it wasn't announced on the dev list, the JIRA ticket created to attach patches was speciafically for the community. and the branch creation was also discussed. Code provided by Fujitsu employees will never go through me with direct commit, it will all be added as patches, even extra tests and documentation as we want them and everyone else willing to help get the credit for it. we do the same. Folks provide patches and jira tickets to describe the problem. Furthermore, I personally didn't announce it because the branch will be very instable for a week or two until we finish adding the missing signatures (impl might not even always compile). dev@ is a developers
[jira] Updated: (TRINIDAD-205) Need to avoid IE's number of CSS selectors limitation
[
https://issues.apache.org/jira/browse/TRINIDAD-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Lessard updated TRINIDAD-205:
---
Resolution: Fixed
Fix Version/s: 1.0.10-core
1.2.10-core
Status: Resolved (was: Patch Available)
Applied the patch to both trunks
1.0.10 : Revision 689820
1.2.10 : Revision 689844
Need to avoid IE's number of CSS selectors limitation
-
Key: TRINIDAD-205
URL: https://issues.apache.org/jira/browse/TRINIDAD-205
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.0.1-incubating-core-SNAPSHOT
Reporter: Jeanne Waldman
Assignee: Simon Lessard
Fix For: 1.2.10-core, 1.0.10-core
Attachments: TRINIDAD-205.patch
it turns out that IE has a limit to the size of a CSS file. It's not the
actual size of the file, but rather it is the
# of CSS selectors. I did a test and found out that the limit is 4095 CSS
selectors.
Firefox doesn't appear to have a limit.
As you may know, the CSS file we generate contains both compressed and
uncompressed styles, like this:
.af_inputText_content, .x01 {background-color: blue}
Our renderers render a shortened styleclass, unless
the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml, then it
renders the long styleclass.
input class=x01...
Ok, that's the background.
*The problem* is that because we have a lot of custom components that we've
built on top of Trinidad, and our customers
have built custom components, etc, and these all have skinning,
we have bumped up against the 4095 selector limit in IE. All selectors after
the 4095th one are ignored.
*A quick fix*, and probably a good one for a long time, is to render the
styles in compressed mode when compression is on,
or in uncompressed mode when compression if off. That will reduce our style
selectors by 1/2, and will help performance to boot. :)
I can also add a warning if we go past 4095 selectors for IE.
Another solution is to break up the file into multiple files when I've
reached the limit in one file, and include
all the css files into the rendered page. I can do this in addition to the
quick fix when I have more time.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: JSF2.0 implementation
On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Simon, On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching [EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. As mentioned by other people, there was a vote about this a while back . Why did I create it just now? Simply because my company agreed to provide some resource to help with the implementation and we were ready to get started. One might ask here for a CCLA ;-) We did that for Oracle way back, and update once in a while all the contributors, that have signed the iCLA. Yeah, but Fujistu signed a CCLA already when I became commiter, so that's a non issue as well. good. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. To be honest, I find this irrelevant, it's a branch, not a trunk and I'll most likely do some branch merging when core 1.2.x get release and the plugin might have to change a little to support jsfVersion 2.0. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. I see even less relevance in that statement. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. The code was coded just yesterday by me and is not much at all, creating missing classes for the JavaDoc change log is in no matter a large amount in term of complexity. Also since I was the only author of it (my teammates will wait until I have added the signatures). There's absolutely no need of code grant either. I agree on the code grant, b/c of it is really pretty trivial to create those API classes/interfaces (based on the javadoc log, as I said before). @signatures: you mean the iCLA / CCLA, aren't you ? nah, I meant method signatures, it will be easier for my teammates to know what they have to do once there's a nice // TODO: Convert to JSF 2.0 added in every new method's body. As far as I understand the legal issues (might have to fallback to [EMAIL PROTECTED] though), they won't need a CLA until they become commiters. I don't know if I should have the company add their names to the CCLA no. wrong cla == contributor license agreement. I usually ask for that after one or two patches. Never been an issue at all. We (from ORA) add those contributors to our CCLA, and fax the update to Sam Ruby (our ASF secretary). however. Technically, we aren't bound contractualy by any intellectual property transfer with my employer and we're developping outside normal business hours so we aren't directly paid either for it so I don't know if adding their name to the CCLA is even needed or not. that means, what you develop on your sparetime is yours... NO CCLA update required. Cool -Matthias ~ Simon And with 3 branches to now maintain, we need to discuss whether and when we phase out maintenance of the jsf-1.1 branch. Currently when users provide patches in jira, they almost always provide a patch against only one version and the committer ports it, which does increase the load on existing committers. When do we stop asking committers to do this when patching bugs? I can take care of the branch merging, this is how we handled the trinidad 1.2 branch at first, Adam would do the merging every now and then, so I'm not asking the committers to do some extra work. yup. not a big deal. Also I doubt that that many folks will work there, on the branch. If the branch needs some merging... fine as well, IMO. To repeat, I'm *happy* that jsf2.0 implementation is in progress, and appreciate people contributing time to write an ASF-2.0-licensed implementation. But it is a standard saying at Apache that community is more important than code, and the community aspect here seems to have been rather neglected... I don't agree at all here. Although it wasn't announced on the dev list, the JIRA ticket created to attach patches was speciafically for the community. and the branch creation was also discussed. Code provided by Fujitsu employees will never go through me with direct commit, it
Re: JSF2.0 implementation
I am willing (as always) to contribute as much as my time permits to the JSF 2.0 implementation. I tried to find in the list what is going to be the big picture, the roadmap to have a JSF 2.0 implementation. Do we have something like that? How are we going to integrate Facelets, for instance? (good that is now under ASL!). What part are you developing at the moment? Thanks! Bruno 2008/8/28 Matthias Wessendorf [EMAIL PROTECTED] On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Simon, On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching [EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. As mentioned by other people, there was a vote about this a while back . Why did I create it just now? Simply because my company agreed to provide some resource to help with the implementation and we were ready to get started. One might ask here for a CCLA ;-) We did that for Oracle way back, and update once in a while all the contributors, that have signed the iCLA. Yeah, but Fujistu signed a CCLA already when I became commiter, so that's a non issue as well. good. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. To be honest, I find this irrelevant, it's a branch, not a trunk and I'll most likely do some branch merging when core 1.2.x get release and the plugin might have to change a little to support jsfVersion 2.0. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. I see even less relevance in that statement. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. The code was coded just yesterday by me and is not much at all, creating missing classes for the JavaDoc change log is in no matter a large amount in term of complexity. Also since I was the only author of it (my teammates will wait until I have added the signatures). There's absolutely no need of code grant either. I agree on the code grant, b/c of it is really pretty trivial to create those API classes/interfaces (based on the javadoc log, as I said before). @signatures: you mean the iCLA / CCLA, aren't you ? nah, I meant method signatures, it will be easier for my teammates to know what they have to do once there's a nice // TODO: Convert to JSF 2.0 added in every new method's body. As far as I understand the legal issues (might have to fallback to [EMAIL PROTECTED] though), they won't need a CLA until they become commiters. I don't know if I should have the company add their names to the CCLA no. wrong cla == contributor license agreement. I usually ask for that after one or two patches. Never been an issue at all. We (from ORA) add those contributors to our CCLA, and fax the update to Sam Ruby (our ASF secretary). however. Technically, we aren't bound contractualy by any intellectual property transfer with my employer and we're developping outside normal business hours so we aren't directly paid either for it so I don't know if adding their name to the CCLA is even needed or not. that means, what you develop on your sparetime is yours... NO CCLA update required. Cool -Matthias ~ Simon And with 3 branches to now maintain, we need to discuss whether and when we phase out maintenance of the jsf-1.1 branch. Currently when users provide patches in jira, they almost always provide a patch against only one version and the committer ports it, which does increase the load on existing committers. When do we stop asking committers to do this when patching bugs? I can take care of the branch merging, this is how we handled the trinidad 1.2 branch at first, Adam would do the merging every now and then, so I'm not asking the committers to do some extra work. yup. not a big deal. Also I doubt that that many folks will work there, on the branch. If the branch needs some merging... fine as well, IMO. To repeat, I'm *happy* that
Re: JSF2.0 implementation
On Thu, Aug 28, 2008 at 5:30 PM, Bruno Aranda [EMAIL PROTECTED] wrote: I am willing (as always) to contribute as much as my time permits to the JSF 2.0 implementation. I tried to find in the list what is going to be the big picture, the roadmap to have a JSF 2.0 implementation. Do we have something no. I was beaten by Simon. My plan was to add those interfaces/APIs, that are already know. like that? How are we going to integrate Facelets, for instance? (good that is now under ASL!). What part are you developing at the moment? The RI folks checked it into their repos, AFAIK. I bet to work under CDDL ;-) These parts are not (yet) public, I think. Not sure... -Matthias Thanks! Bruno 2008/8/28 Matthias Wessendorf [EMAIL PROTECTED] On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Simon, On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching [EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. As mentioned by other people, there was a vote about this a while back . Why did I create it just now? Simply because my company agreed to provide some resource to help with the implementation and we were ready to get started. One might ask here for a CCLA ;-) We did that for Oracle way back, and update once in a while all the contributors, that have signed the iCLA. Yeah, but Fujistu signed a CCLA already when I became commiter, so that's a non issue as well. good. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. To be honest, I find this irrelevant, it's a branch, not a trunk and I'll most likely do some branch merging when core 1.2.x get release and the plugin might have to change a little to support jsfVersion 2.0. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. I see even less relevance in that statement. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. The code was coded just yesterday by me and is not much at all, creating missing classes for the JavaDoc change log is in no matter a large amount in term of complexity. Also since I was the only author of it (my teammates will wait until I have added the signatures). There's absolutely no need of code grant either. I agree on the code grant, b/c of it is really pretty trivial to create those API classes/interfaces (based on the javadoc log, as I said before). @signatures: you mean the iCLA / CCLA, aren't you ? nah, I meant method signatures, it will be easier for my teammates to know what they have to do once there's a nice // TODO: Convert to JSF 2.0 added in every new method's body. As far as I understand the legal issues (might have to fallback to [EMAIL PROTECTED] though), they won't need a CLA until they become commiters. I don't know if I should have the company add their names to the CCLA no. wrong cla == contributor license agreement. I usually ask for that after one or two patches. Never been an issue at all. We (from ORA) add those contributors to our CCLA, and fax the update to Sam Ruby (our ASF secretary). however. Technically, we aren't bound contractualy by any intellectual property transfer with my employer and we're developping outside normal business hours so we aren't directly paid either for it so I don't know if adding their name to the CCLA is even needed or not. that means, what you develop on your sparetime is yours... NO CCLA update required. Cool -Matthias ~ Simon And with 3 branches to now maintain, we need to discuss whether and when we phase out maintenance of the jsf-1.1 branch. Currently when users provide patches in jira, they almost always provide a patch against only one version and the committer ports it, which does increase the load on existing committers. When do we stop asking committers to do this when patching bugs? I can take care of the branch merging, this is
[jira] Commented: (TRINIDAD-1198) inputText looses its values when switched from disabled to enabled using PPR
[ https://issues.apache.org/jira/browse/TRINIDAD-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626636#action_12626636 ] Andrew Robinson commented on TRINIDAD-1198: --- This does not sound like a bug. A disabled component will not submit a value to the server. So therefore, the value must come from the EL expression / backing bean. I presume that your backing bean has no value? Workarounds: 1) use conversation (3rd party scope) or session scope for you backing bean 2) use t:saveState (tomahawk) inputText looses its values when switched from disabled to enabled using PPR Key: TRINIDAD-1198 URL: https://issues.apache.org/jira/browse/TRINIDAD-1198 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Reporter: Stephen Friedrich Title says it all: When a disabled text field contains some text, then some PPR action sets disabled=false on that field, then the field losses its value. All text is gone. See TRINIDAD-1130 for an example app (the bug also still occurs with current svn version). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JSF2.0 implementation
Hi Bruno, So far my planing was: sequential 1. Create all new API classes: done 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in their body when they aren't abstract: in progress and I already found some strange stuff that I might raise on the EG group discussions as for why Application.getResourceHandler isn't abstract while all other get handler methods are: in progress *** At that point, IMPL will no longer compile *** 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment in their body *** Everything should compile but don't work at all *** parallel 4. Modify the build plugin to include jsf 2.0 changes 5. Implement the API changes 6. Implement the IMPL changes 7. Implement the JS library I would really like to use Facelets code when required, but we'll have to make sure it's alright with legal discuss first I think, I'm not well versed enough in this kind of very specific issues. It's a very high level roadmap, We should probably use much finer granularity for point 5 to 7, but I'm not there yet. Regards, ~ Simon On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda [EMAIL PROTECTED]wrote: I am willing (as always) to contribute as much as my time permits to the JSF 2.0 implementation. I tried to find in the list what is going to be the big picture, the roadmap to have a JSF 2.0 implementation. Do we have something like that? How are we going to integrate Facelets, for instance? (good that is now under ASL!). What part are you developing at the moment? Thanks! Bruno 2008/8/28 Matthias Wessendorf [EMAIL PROTECTED] On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Simon, On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching [EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. As mentioned by other people, there was a vote about this a while back . Why did I create it just now? Simply because my company agreed to provide some resource to help with the implementation and we were ready to get started. One might ask here for a CCLA ;-) We did that for Oracle way back, and update once in a while all the contributors, that have signed the iCLA. Yeah, but Fujistu signed a CCLA already when I became commiter, so that's a non issue as well. good. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. To be honest, I find this irrelevant, it's a branch, not a trunk and I'll most likely do some branch merging when core 1.2.x get release and the plugin might have to change a little to support jsfVersion 2.0. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. I see even less relevance in that statement. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. The code was coded just yesterday by me and is not much at all, creating missing classes for the JavaDoc change log is in no matter a large amount in term of complexity. Also since I was the only author of it (my teammates will wait until I have added the signatures). There's absolutely no need of code grant either. I agree on the code grant, b/c of it is really pretty trivial to create those API classes/interfaces (based on the javadoc log, as I said before). @signatures: you mean the iCLA / CCLA, aren't you ? nah, I meant method signatures, it will be easier for my teammates to know what they have to do once there's a nice // TODO: Convert to JSF 2.0 added in every new method's body. As far as I understand the legal issues (might have to fallback to [EMAIL PROTECTED] though), they won't need a CLA until they become commiters. I don't know if I should have the company add their names to the CCLA no. wrong cla == contributor license agreement. I usually ask for that after one or two patches. Never been an issue at all. We (from ORA) add those contributors to our CCLA, and fax the update to Sam Ruby (our ASF secretary). however. Technically, we aren't bound
[jira] Updated: (TRINIDAD-1191) Delayed loading of renderers to facilitate faster start up time
[ https://issues.apache.org/jira/browse/TRINIDAD-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ari hadi updated TRINIDAD-1191: --- Status: Patch Available (was: Open) Delayed loading of renderers to facilitate faster start up time Key: TRINIDAD-1191 URL: https://issues.apache.org/jira/browse/TRINIDAD-1191 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Ari hadi Attachments: RenderKitBase.java Original Estimate: 168h Remaining Estimate: 168h Trinidad's RenderKitBase class has support for optimized loading of renderer. Class loading optimization will lazily loads renderers and reduces the loading time, since 20% of the time used for opening the file the first time is for class loading. Renderers that are provided in the RenderKit-specific config file will be loaded lazily. This mapping file is similar to the one in META-INF/oracle.adf.rich.renderkit. Right now, it will only look for one copy of the renderkit-specific config file. We should be able to tweak this code to grab all files found at the specific path instead of just one. This will allow any other custom component developers to lazily load their Renderers by providing their own mapping file. Note: At the moment, we are doing more tests to verify the lazy renderer to load other custom components lazily. Please do not commit this patch until then. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-982) SelectOneRow missing disabled and readonly attributes as described in TLD (patch provided)
[ https://issues.apache.org/jira/browse/TOMAHAWK-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated TOMAHAWK-982: Resolution: Fixed Fix Version/s: 1.1.7-SNAPSHOT Assignee: Leonardo Uribe (was: Hazem Saleh) Status: Resolved (was: Patch Available) I have checked the code and there are two points: 1. The patch does not take into account the config param org.apache.myfaces.READONLY_AS_DISABLED_FOR_SELECTS. 2. The readonly parameter is already written, so there is no need to do this again. After this, There was committed a solution taking into account this two points. thanks for the suggestions SelectOneRow missing disabled and readonly attributes as described in TLD (patch provided) -- Key: TOMAHAWK-982 URL: https://issues.apache.org/jira/browse/TOMAHAWK-982 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.6 Reporter: Mike Gillan Assignee: Leonardo Uribe Priority: Trivial Fix For: 1.1.7-SNAPSHOT Attachments: SelectOneRow.patch, SelectOneRowRenderer.patch The SelectOneRow sandbox component does not render the HTML 'disabled' or 'readonly' attributes as specified by the component's TLD documentation. (Source code has a comment indicating that these features have not been implemented.) I needed this functionality so I implemented it. (Patch provided) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-922) JSF-1.2: JspTilesViewHandlerImpl
[ https://issues.apache.org/jira/browse/TOMAHAWK-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626721#action_12626721 ] Leonardo Uribe commented on TOMAHAWK-922: - Since the solution proposed works I'll close this issue as fixed (after release of myfaces 1.2.4) JSF-1.2: JspTilesViewHandlerImpl Key: TOMAHAWK-922 URL: https://issues.apache.org/jira/browse/TOMAHAWK-922 Project: MyFaces Tomahawk Issue Type: Bug Components: Tiles Affects Versions: 1.1.5-SNAPSHOT Environment: MyFaces Tomahawk SVN HEAD + JSF-1.2_03 (Reference implementation) + JDK-1.5.0_11 + Tomcat-6.0.10 Reporter: Jesper Pedersen The JspTilesViewHandlerImpl doesn't work under JSF-1.2 (RI) as it doesn't deliver any output. Steps: 1) Get myfaces-example-tiles-1.1.5-SNAPSHOT.war 2) Replace MyFaces-Core with JSF-1.2 (RI) in WEB-INF/lib 3) Deploy on Tomcat-6.0.10 4) Go to http://localhost:8080/myfaces-example-tiles-1.1.5-SNAPSHOT/ Generated HTML: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN head meta http-equiv=Content-Type content=text/html;CHARSET=iso-8859-1 / titleMyfaces - Tiles/title link rel=stylesheet type=text/css href=css/tiles.css / /head /html Basically I'm unable to use Tomahawk under JSF-1.2 currently, so any pointers on how to fix this issue or to provide more information would be great. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1198) inputText looses its values when switched from disabled to enabled using PPR
[ https://issues.apache.org/jira/browse/TRINIDAD-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626724#action_12626724 ] Stephen Friedrich commented on TRINIDAD-1198: - Yes, like I said this isn't a Trinidad bug - sorry for reporting this as an issue. I wonder how I can update the required attribute without updating the value?! IMHO this is another point were JSF makes simple things too hard (with JSP I could simply use javascript without involving the server). I think I'll try to still do the autosubmit using PPR (so that the component tree on the server side is updated correcty), remove the partialTriggers attribute from the inputText and use javascript to manually change the disabled state (though I am a little afraid of interfering with Trinidad javascript code that handles the attribute). inputText looses its values when switched from disabled to enabled using PPR Key: TRINIDAD-1198 URL: https://issues.apache.org/jira/browse/TRINIDAD-1198 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Reporter: Stephen Friedrich Title says it all: When a disabled text field contains some text, then some PPR action sets disabled=false on that field, then the field losses its value. All text is gone. See TRINIDAD-1130 for an example app (the bug also still occurs with current svn version). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-542) forceId does not work on dataTable
[
https://issues.apache.org/jira/browse/TOMAHAWK-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626751#action_12626751
]
Leonardo Uribe commented on TOMAHAWK-542:
-
If you have for example this code (see dataList.jsp on tomahawk examples):
t:dataList id=data4
styleClass=standardList
var=country
value=#{countryList.countries}
layout=orderedList
forceId=true
h:inputText value=#{country.name} /
/t:dataList
the actual code is this (this was because the getClientId previous code was
very old):
ol id=data4 class=standardList
liinput id=data4_0:_idJsp13 name=data4_0:_idJsp13 type=text
value=AUSTRIA //li
liinput id=data4_1:_idJsp13 name=data4_1:_idJsp13 type=text
value=AZERBAIJAN //li
liinput id=data4_2:_idJsp13 name=data4_2:_idJsp13 type=text
value=BAHAMAS //li
liinput id=data4_3:_idJsp13 name=data4_3:_idJsp13 type=text
value=BAHRAIN //li
liinput id=data4_4:_idJsp13 name=data4_4:_idJsp13 type=text
value=BANGLADESH //li
liinput id=data4_5:_idJsp13 name=data4_5:_idJsp13 type=text
value=BARBADOS //li
/ol
the expected html rendered code should be this:
ol id=data4 class=standardList
liinput id=data4:0:_idJsp13 name=data4:0:_idJsp13 type=text
value=AUSTRIA //li
liinput id=data4:1:_idJsp13 name=data4:1:_idJsp13 type=text
value=AZERBAIJAN //li
liinput id=data4:2:_idJsp13 name=data4:2:_idJsp13 type=text
value=BAHAMAS //li
liinput id=data4:3:_idJsp13 name=data4:3:_idJsp13 type=text
value=BAHRAIN //li
liinput id=data4:4:_idJsp13 name=data4:4:_idJsp13 type=text
value=BANGLADESH //li
liinput id=data4:5:_idJsp13 name=data4:5:_idJsp13 type=text
value=BARBADOS //li
/ol
If you have this:
t:dataList id=data4
styleClass=standardList
var=country
value=#{countryList.countries}
layout=orderedList
h:inputText value=#{country.name} /
/t:dataList
The result should be this:
ol id=_idJsp2:data4 class=standardList
liinput id=_idJsp2:data4:0:_idJsp13 name=_idJsp2:data4:0:_idJsp13
type=text value=AUSTRIA //li
liinput id=_idJsp2:data4:1:_idJsp13 name=_idJsp2:data4:1:_idJsp13
type=text value=AZERBAIJAN //li
liinput id=_idJsp2:data4:2:_idJsp13 name=_idJsp2:data4:2:_idJsp13
type=text value=BAHAMAS //li
liinput id=_idJsp2:data4:3:_idJsp13 name=_idJsp2:data4:3:_idJsp13
type=text value=BAHRAIN //li
liinput id=_idJsp2:data4:4:_idJsp13 name=_idJsp2:data4:4:_idJsp13
type=text value=BANGLADESH //li
liinput id=_idJsp2:data4:5:_idJsp13 name=_idJsp2:data4:5:_idJsp13
type=text value=BARBADOS //li
/ol
If you have this:
t:dataList id=data4
styleClass=standardList
var=country
value=#{countryList.countries}
layout=orderedList
t:inputText forceId=true forceIdIndex=true value=#{country.name}
/
/t:dataList
The result should be this:
ol id=_idJsp2:data4 class=standardList
liinput id=_idJsp13[0] name=_idJsp13[0] type=text value=AUSTRIA
//li
liinput id=_idJsp13[1] name=_idJsp13[1] type=text value=AZERBAIJAN
//li
liinput id=_idJsp13[2] name=_idJsp13[2] type=text value=BAHAMAS
//li
liinput id=_idJsp13[3] name=_idJsp13[3] type=text value=BAHRAIN
//li
liinput id=_idJsp13[4] name=_idJsp13[4] type=text value=BANGLADESH
//li
liinput id=_idJsp13[5] name=_idJsp13[5] type=text value=BARBADOS
//li
/ol
The previous behavior is consistent, so it will be applied.
For do this, AbstractHtmlDataList getClientId() method should be removed and
moved HtmlComponentUtils.getClientId(this, getRenderer(context), context)
related code to HtmlDataTableHack.
With this solution, this issue will be closed, but TOMAHAWK-1316 will be closed
as cannot duplicate, because on the latest 1.1.7-SNAPSHOT code the error is not
present.
forceId does not work on dataTable
--
Key: TOMAHAWK-542
URL: https://issues.apache.org/jira/browse/TOMAHAWK-542
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Extended Datatable
Affects Versions: 1.1.3
Environment: tomcat 5.5, java 1.5
Reporter: Torsten Krah
Priority: Minor
Attachments: HtmlDataList.java, HtmlDataTableHack.java
Using forceId=true with a extended dataTable still gives me the
generated one - the id gets not forced in the generated output.
t:panelGroup e.g. with forceId works.
According to the docs ( http://myfaces.apache.org/tomahawk/forceId.html ) it
should work with all t: components.
kind regards
Torsten
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1202) WHEN CLICK THE PANELACCORDION, NOTHING HAPPENS
WHEN CLICK THE PANELACCORDION, NOTHING HAPPENS -- Key: TRINIDAD-1202 URL: https://issues.apache.org/jira/browse/TRINIDAD-1202 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Environment: Windows Mobile 6, Windows Mobile 5 and BlackBerry browsers Reporter: Tadashi Enomori Priority: Minor When show/hide icon for a panel accordion item is clicked, the detail associated with the item should be shown/hidden. There are three problems in the code. 1. The PPR capability is not checked correctly and for WM6, PPR is not enabled where it should be. 2. For WM5, PPR capability is set while Trinidad does not support PPR on WM5 browser. 3. For non PPR browse, such as WM5 and BlackBerry browsers, the hidden field to store parameter targetItem is missing and thus renderer cannot correctly process a request for show/hide event. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1316) Element Id inside datalist do not render correctly
[
https://issues.apache.org/jira/browse/TOMAHAWK-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved TOMAHAWK-1316.
--
Resolution: Cannot Reproduce
Assignee: Leonardo Uribe
The problem is present on 1.1.6 but it can't be reproduced on 1.1.7-SNAPSHOT,
maybe due to changes of myfaces-builder-plugin, or other changes done before.
Element Id inside datalist do not render correctly
--
Key: TOMAHAWK-1316
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1316
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Data List
Affects Versions: 1.1.6
Environment: - jdk 1.6
- Server: glassfish 2
Reporter: Nguyen Vu Tuan Nam
Assignee: Leonardo Uribe
The element id were rendered incorrect the first time but render correctly
from the second time.
The first time:
span id=investorList
span id=orderList[0]
input type=checkbox name=orderList[0]_6:unHoldCash
id=orderList[0]_6:unHoldCash value=false /
/span
/span
The second time:
span id=form:investorList
span id=form:investorList:0:orderList
input type=checkbox name=form:investorList:0:orderList:6:unHoldCash
id=form:investorList:0:orderList:6:unHoldCash value=true
/span
/span
Source:
t:dataList id=investorList layout = simple
value=#{EODOrderSummary.investorOrders} var=investorOrder
rowIndexVar=parentIndex forceIdIndex=true forceId=true
t:dataList id =orderList layout=simple
value=#{investorOrder.placedOrders} var=orderSummaryInfo
rowIndexVar=childIndex forceIdIndex=true forceId=true
t:selectBooleanCheckbox id=unHoldCash
value=#{orderSummaryInfo.unHoldEnabled}
rendered=#{orderSummaryInfo.buyingOrder orderSummaryInfo.diffAmount 0
EODOrderSummary.today} /
EODOrderSummary scope is request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1203) DATE SELECTION IN INPUTDATE ON BLACKBERRY THROWS VIEWEXPIREDEXCEPTION
DATE SELECTION IN INPUTDATE ON BLACKBERRY THROWS VIEWEXPIREDEXCEPTION - Key: TRINIDAD-1203 URL: https://issues.apache.org/jira/browse/TRINIDAD-1203 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Environment: WebLogic Server only. This is a specific to browsers that do not support multiple windows (pop up). Reporter: Tadashi Enomori Priority: Minor This problem is caused by the variation of filter chain implementation in servers. Trinidad filter implementation invokes chain.doFilter() for a same request, but WLS does not handle the case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1204) SELECTRANGECHOICEBAR SELECTION APPENDS PREVIOUS SELECTION
SELECTRANGECHOICEBAR SELECTION APPENDS PREVIOUS SELECTION - Key: TRINIDAD-1204 URL: https://issues.apache.org/jira/browse/TRINIDAD-1204 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Environment: Windows Mobile 6. Reporter: Tadashi Enomori Priority: Minor On Window Mobile 6 browser, each time a user select an item in a selectRangeChoiceBar, the resulting fragment is appended to the previous fragment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1205) PANELCHOICE APPENDS PREVIOUS CHOICES
PANELCHOICE APPENDS PREVIOUS CHOICES Key: TRINIDAD-1205 URL: https://issues.apache.org/jira/browse/TRINIDAD-1205 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Environment: Windows Mobile 6 Reporter: Tadashi Enomori Priority: Minor This is similar to Trinidad-1204, but the same problem happens with panelChoice component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1206) BlackBerry navigationPane does not show selected item
BlackBerry navigationPane does not show selected item - Key: TRINIDAD-1206 URL: https://issues.apache.org/jira/browse/TRINIDAD-1206 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Environment: BlackBerry browser only. Reporter: Tadashi Enomori Priority: Minor Different navigation panes are rendered properly (list, page items, choice,tabs...), however the first time the component is loaded the focused tab/list item/.. are NOT rendered as selected. Neither when switching the focus to a different tab/page item/bar item/button/list item, these are not rendered as selected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1208) DOCUMENT TYPE FOR JAVASCRIPT IS MISSING
DOCUMENT TYPE FOR JAVASCRIPT IS MISSING --- Key: TRINIDAD-1208 URL: https://issues.apache.org/jira/browse/TRINIDAD-1208 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Environment: BlackBerry, WebLogic Server 10.3. Reporter: Tadashi Enomori Priority: Minor When running on WLS, client receives response JavaScript document without document type. On some mobile browsers, this causes problems and the document is not recognized as a JavaScript document. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1911) Implement JSF 2.0 logic at TODO #1
Implement JSF 2.0 logic at TODO #1 -- Key: MYFACES-1911 URL: https://issues.apache.org/jira/browse/MYFACES-1911 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Simon Lessard Priority: Minor In class: javax.faces.application.Application Implement: public UIComponent createComponent(FacesContext context, String componentType, String rendererType) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1912) Implement JSF 2.0 logic at TODO #2
Implement JSF 2.0 logic at TODO #2 -- Key: MYFACES-1912 URL: https://issues.apache.org/jira/browse/MYFACES-1912 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Simon Lessard In class: javax.faces.application.Application Implement: public UIComponent createComponent(ValueExpression componentExpression, FacesContext context, String componentType, String rendererType) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1914) Implement JSF 2.0 logic at TODO #4
Implement JSF 2.0 logic at TODO #4 -- Key: MYFACES-1914 URL: https://issues.apache.org/jira/browse/MYFACES-1914 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Simon Lessard Priority: Trivial In class: javax.faces.application.Application Implement: public ProjectStage getProjectStage() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1916) Implement JSF 2.0 logic at TODO #6
Implement JSF 2.0 logic at TODO #6 -- Key: MYFACES-1916 URL: https://issues.apache.org/jira/browse/MYFACES-1916 Project: MyFaces Core Issue Type: Task Components: JSR-314 Reporter: Simon Lessard Priority: Trivial In class: javax.faces.application.Application Implement: public void setResourceHandler(ResourceHandler resourceHandler) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1918) Implement JSF 2.0 logic at TODO #8
Implement JSF 2.0 logic at TODO #8 -- Key: MYFACES-1918 URL: https://issues.apache.org/jira/browse/MYFACES-1918 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Simon Lessard Priority: Trivial In class: javax.faces.application.Application Implement: public void subscribeToEvent(Class? extends SystemEvent systemEventClass, SystemEventListener listener) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1922) Implement JSF 2.0 logic at TODO #17
Implement JSF 2.0 logic at TODO #17 --- Key: MYFACES-1922 URL: https://issues.apache.org/jira/browse/MYFACES-1922 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.component.UIViewRoot Implement: public void addComponentResource(FacesContext context, UIComponent componentResource) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1924) Implement JSF 2.0 logic at TODO #18
Implement JSF 2.0 logic at TODO #18 --- Key: MYFACES-1924 URL: https://issues.apache.org/jira/browse/MYFACES-1924 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.component.UIViewRoot Implement: public void addComponentResource(FacesContext context, UIComponent componentResource, String target) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1917) Implement JSF 2.0 logic at TODO #7
Implement JSF 2.0 logic at TODO #7 -- Key: MYFACES-1917 URL: https://issues.apache.org/jira/browse/MYFACES-1917 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Simon Lessard Priority: Trivial In class: javax.faces.application.Application Implement: public void subscribeToEvent(Class? extends SystemEvent systemEventClass, Class sourceClass, SystemEventListener listener) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1919) Implement JSF 2.0 logic at TODO #9
Implement JSF 2.0 logic at TODO #9 -- Key: MYFACES-1919 URL: https://issues.apache.org/jira/browse/MYFACES-1919 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Simon Lessard Priority: Trivial In class: javax.faces.application.Application Implement: public void unsubscribeFromEvent(Class? extends SystemEvent systemEventClass, Class sourceClass, SystemEventListener listener) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1926) Implement JSF 2.0 logic at TODO #20
Implement JSF 2.0 logic at TODO #20 --- Key: MYFACES-1926 URL: https://issues.apache.org/jira/browse/MYFACES-1926 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.component.UIViewRoot Implement: public MapString,Object getViewMap() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1920) Implement JSF 2.0 logic at TODO #10
Implement JSF 2.0 logic at TODO #10 --- Key: MYFACES-1920 URL: https://issues.apache.org/jira/browse/MYFACES-1920 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Simon Lessard Priority: Trivial In class: javax.faces.application.Application Implement: public void unsubscribeFromEvent(Class? extends SystemEvent systemEventClass, SystemEventListener listener) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1921) Implement JSF 2.0 logic at TODO #16
Implement JSF 2.0 logic at TODO #16 --- Key: MYFACES-1921 URL: https://issues.apache.org/jira/browse/MYFACES-1921 Project: MyFaces Core Issue Type: Task Reporter: Fred Allard Priority: Minor In class: javax.faces.component.UIComponent Implement: public void unsubscribeToEvent(Class? extends SystemEvent eventClass, ComponentSystemEventListener componentListener) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1927) Implement JSF 2.0 logic at TODO #21
Implement JSF 2.0 logic at TODO #21 --- Key: MYFACES-1927 URL: https://issues.apache.org/jira/browse/MYFACES-1927 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.component.UIViewRoot Implement: public MapString,Object getViewMap(boolean create) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1928) Implement JSF 2.0 logic at TODO #22
Implement JSF 2.0 logic at TODO #22 --- Key: MYFACES-1928 URL: https://issues.apache.org/jira/browse/MYFACES-1928 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.component.UIViewRoot Implement: public void processEvent(ComponentSystemEvent event) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1929) Implement JSF 2.0 logic at TODO #23
Implement JSF 2.0 logic at TODO #23 --- Key: MYFACES-1929 URL: https://issues.apache.org/jira/browse/MYFACES-1929 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.component.UIViewRoot Implement: public void removeComponentResource(FacesContext context, UIComponent componentResource, String target) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1931) CLONE -Implement JSF 2.0 logic at TODO #35
CLONE -Implement JSF 2.0 logic at TODO #35 -- Key: MYFACES-1931 URL: https://issues.apache.org/jira/browse/MYFACES-1931 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jean-François Montreuil Priority: Minor In class: javax.faces.component.UIViewRoot Implement: public void removeComponentResource(FacesContext context, UIComponent componentResource, String target) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1932) Implement JSF 2.0 logic at TODO #24
Implement JSF 2.0 logic at TODO #24 --- Key: MYFACES-1932 URL: https://issues.apache.org/jira/browse/MYFACES-1932 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.context.ExternalContext Implement: public void addResponseCookie(String name, String value, MapString,Object properties) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1933) Implement JSF 2.0 logic at TODO #24
Implement JSF 2.0 logic at TODO #24 --- Key: MYFACES-1933 URL: https://issues.apache.org/jira/browse/MYFACES-1933 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.context.ExternalContext Implement: public String getMimeType(String file) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1934) Implement JSF 2.0 logic at TODO #25
Implement JSF 2.0 logic at TODO #25 --- Key: MYFACES-1934 URL: https://issues.apache.org/jira/browse/MYFACES-1934 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.context.ExternalContext Implement: public String getRealPath(String path) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1940) Implement JSF 2.0 logic at TODO #29
Implement JSF 2.0 logic at TODO #29 --- Key: MYFACES-1940 URL: https://issues.apache.org/jira/browse/MYFACES-1940 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.context.ExternalContext Implement: public OutputStream getResponseOutputStream() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1938) Implement JSF 2.0 logic at TODO #28
Implement JSF 2.0 logic at TODO #28 --- Key: MYFACES-1938 URL: https://issues.apache.org/jira/browse/MYFACES-1938 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.context.ExternalContext Implement: public int getRequestServerPort() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1937) Implement JSF 2.0 logic at TODO #27
Implement JSF 2.0 logic at TODO #27 --- Key: MYFACES-1937 URL: https://issues.apache.org/jira/browse/MYFACES-1937 Project: MyFaces Core Issue Type: Task Components: website Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.context.ExternalContext Implement: public String getRequestServerName() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1939) Implement JSF 2.0 logic at TODO #33
Implement JSF 2.0 logic at TODO #33 --- Key: MYFACES-1939 URL: https://issues.apache.org/jira/browse/MYFACES-1939 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jean-François Montreuil Priority: Minor In class: javax.faces.context.FacesContext Implement: public boolean isPostback() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JSF2.0 implementation
Thank you Simon. I will join this soon. On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard [EMAIL PROTECTED]wrote: Hi Bruno, So far my planing was: sequential 1. Create all new API classes: done 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in their body when they aren't abstract: in progress and I already found some strange stuff that I might raise on the EG group discussions as for why Application.getResourceHandler isn't abstract while all other get handler methods are: in progress *** At that point, IMPL will no longer compile *** 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment in their body *** Everything should compile but don't work at all *** parallel 4. Modify the build plugin to include jsf 2.0 changes 5. Implement the API changes 6. Implement the IMPL changes 7. Implement the JS library I would really like to use Facelets code when required, but we'll have to make sure it's alright with legal discuss first I think, I'm not well versed enough in this kind of very specific issues. It's a very high level roadmap, We should probably use much finer granularity for point 5 to 7, but I'm not there yet. Regards, ~ Simon On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda [EMAIL PROTECTED]wrote: I am willing (as always) to contribute as much as my time permits to the JSF 2.0 implementation. I tried to find in the list what is going to be the big picture, the roadmap to have a JSF 2.0 implementation. Do we have something like that? How are we going to integrate Facelets, for instance? (good that is now under ASL!). What part are you developing at the moment? Thanks! Bruno 2008/8/28 Matthias Wessendorf [EMAIL PROTECTED] On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Simon, On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching [EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. As mentioned by other people, there was a vote about this a while back . Why did I create it just now? Simply because my company agreed to provide some resource to help with the implementation and we were ready to get started. One might ask here for a CCLA ;-) We did that for Oracle way back, and update once in a while all the contributors, that have signed the iCLA. Yeah, but Fujistu signed a CCLA already when I became commiter, so that's a non issue as well. good. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. To be honest, I find this irrelevant, it's a branch, not a trunk and I'll most likely do some branch merging when core 1.2.x get release and the plugin might have to change a little to support jsfVersion 2.0. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. I see even less relevance in that statement. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. The code was coded just yesterday by me and is not much at all, creating missing classes for the JavaDoc change log is in no matter a large amount in term of complexity. Also since I was the only author of it (my teammates will wait until I have added the signatures). There's absolutely no need of code grant either. I agree on the code grant, b/c of it is really pretty trivial to create those API classes/interfaces (based on the javadoc log, as I said before). @signatures: you mean the iCLA / CCLA, aren't you ? nah, I meant method signatures, it will be easier for my teammates to know what they have to do once there's a nice // TODO: Convert to JSF 2.0 added in every new method's body. As far as I understand the legal issues (might have to fallback to [EMAIL PROTECTED] though), they won't need a CLA until they become commiters. I don't know if I should have the company add their names to the CCLA no. wrong cla == contributor license agreement. I usually ask for that after one or two patches. Never been an issue at all. We (from
[jira] Created: (MYFACES-1941) Implement JSF 2.0 logic at TODO #30
Implement JSF 2.0 logic at TODO #30 --- Key: MYFACES-1941 URL: https://issues.apache.org/jira/browse/MYFACES-1941 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.context.ExternalContext Implement: public void invalidateSession() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1942) Implement JSF 2.0 logic at TODO #32
Implement JSF 2.0 logic at TODO #32 --- Key: MYFACES-1942 URL: https://issues.apache.org/jira/browse/MYFACES-1942 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jean-François Montreuil Priority: Minor In class: javax.faces.context.FacesContext Implement: public PhaseId getCurrentPhaseId() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1943) Implement JSF 2.0 logic at TODO #12
Implement JSF 2.0 logic at TODO #12 --- Key: MYFACES-1943 URL: https://issues.apache.org/jira/browse/MYFACES-1943 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.component.UIComponent Implement: public ListSystemEventListener getListenersForEventClass(Class? extends SystemEvent eventClass) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1930) Implement JSF 2.0 logic at TODO #22
Implement JSF 2.0 logic at TODO #22 --- Key: MYFACES-1930 URL: https://issues.apache.org/jira/browse/MYFACES-1930 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.component.UIViewRoot Implement: public void removeComponentResource(FacesContext context, UIComponent componentResource) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JSF2.0 implementation
Thank :) Although give me 10 minutes or so to fix something stupid I did before doing a checkout. Regards, ~ Simon On Thu, Aug 28, 2008 at 7:16 PM, Hazem Saleh [EMAIL PROTECTED] wrote: Thank you Simon. I will join this soon. On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard [EMAIL PROTECTED]wrote: Hi Bruno, So far my planing was: sequential 1. Create all new API classes: done 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in their body when they aren't abstract: in progress and I already found some strange stuff that I might raise on the EG group discussions as for why Application.getResourceHandler isn't abstract while all other get handler methods are: in progress *** At that point, IMPL will no longer compile *** 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment in their body *** Everything should compile but don't work at all *** parallel 4. Modify the build plugin to include jsf 2.0 changes 5. Implement the API changes 6. Implement the IMPL changes 7. Implement the JS library I would really like to use Facelets code when required, but we'll have to make sure it's alright with legal discuss first I think, I'm not well versed enough in this kind of very specific issues. It's a very high level roadmap, We should probably use much finer granularity for point 5 to 7, but I'm not there yet. Regards, ~ Simon On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda [EMAIL PROTECTED]wrote: I am willing (as always) to contribute as much as my time permits to the JSF 2.0 implementation. I tried to find in the list what is going to be the big picture, the roadmap to have a JSF 2.0 implementation. Do we have something like that? How are we going to integrate Facelets, for instance? (good that is now under ASL!). What part are you developing at the moment? Thanks! Bruno 2008/8/28 Matthias Wessendorf [EMAIL PROTECTED] On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Simon, On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching [EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. As mentioned by other people, there was a vote about this a while back . Why did I create it just now? Simply because my company agreed to provide some resource to help with the implementation and we were ready to get started. One might ask here for a CCLA ;-) We did that for Oracle way back, and update once in a while all the contributors, that have signed the iCLA. Yeah, but Fujistu signed a CCLA already when I became commiter, so that's a non issue as well. good. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. To be honest, I find this irrelevant, it's a branch, not a trunk and I'll most likely do some branch merging when core 1.2.x get release and the plugin might have to change a little to support jsfVersion 2.0. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. I see even less relevance in that statement. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. The code was coded just yesterday by me and is not much at all, creating missing classes for the JavaDoc change log is in no matter a large amount in term of complexity. Also since I was the only author of it (my teammates will wait until I have added the signatures). There's absolutely no need of code grant either. I agree on the code grant, b/c of it is really pretty trivial to create those API classes/interfaces (based on the javadoc log, as I said before). @signatures: you mean the iCLA / CCLA, aren't you ? nah, I meant method signatures, it will be easier for my teammates to know what they have to do once there's a nice // TODO: Convert to JSF 2.0 added in every new method's body. As far as I understand the legal issues (might have to fallback to [EMAIL PROTECTED] though), they won't need a CLA until they become commiters. I don't know if
[jira] Created: (MYFACES-1944) Implement JSF 2.0 logic at TODO #13
Implement JSF 2.0 logic at TODO #13 --- Key: MYFACES-1944 URL: https://issues.apache.org/jira/browse/MYFACES-1944 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.component.UIComponent Implement: protected void popComponentFromEL(FacesContext context) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1945) Implement JSF 2.0 logic at TODO #14
Implement JSF 2.0 logic at TODO #14 --- Key: MYFACES-1945 URL: https://issues.apache.org/jira/browse/MYFACES-1945 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.component.UIComponent Implement: protected void pushComponentToEL(FacesContext context) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1935) Implement JSF 2.0 logic at TODO #25
Implement JSF 2.0 logic at TODO #25 --- Key: MYFACES-1935 URL: https://issues.apache.org/jira/browse/MYFACES-1935 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jean-François Montreuil Priority: Minor In class: javax.faces.context.ExternalContext Implement: public String getRealPath(String path) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1947) Implement JSF 2.0 logic at TODO #15
Implement JSF 2.0 logic at TODO #15 --- Key: MYFACES-1947 URL: https://issues.apache.org/jira/browse/MYFACES-1947 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.component.UIComponent Implement: public void subscribeToEvent(Class? extends SystemEvent eventClass, ComponentSystemEventListener componentListener) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1946) Implement JSF 2.0 logic at TODO #31
Implement JSF 2.0 logic at TODO #31 --- Key: MYFACES-1946 URL: https://issues.apache.org/jira/browse/MYFACES-1946 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Jean-François Montreuil Priority: Minor In class: javax.faces.context.FacesContext Implement: public MapObject,Object getAttributes() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1948) Implement JSF 2.0 logic at TODO #27
Implement JSF 2.0 logic at TODO #27 --- Key: MYFACES-1948 URL: https://issues.apache.org/jira/browse/MYFACES-1948 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.context.ExternalContext Implement: public String getRequestServerName() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1936) Implement JSF 2.0 logic at TODO #26
Implement JSF 2.0 logic at TODO #26 --- Key: MYFACES-1936 URL: https://issues.apache.org/jira/browse/MYFACES-1936 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Fred Allard Priority: Minor In class: javax.faces.context.ExternalContext Implement: public String getRequestScheme() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JSF2.0 implementation
Ok, The branch is now compiling and TODOs of the following format were placed in the newly created methods : // TODO: JSF 2.0 #xx We also created a JIRA ticket of every of those TODOs, so if you feel like trying one, you can add a comment in JIRA saying that you're taking the ticker. Before taking a ticket, make sure that no one else is currently working on it to prevent clashes. The next step on my side is to add more TODOs for the updated methods and create a JIRA ticket for them, then I'll get to coding myself. Thanks, ~ Simon On Thu, Aug 28, 2008 at 7:19 PM, Simon Lessard [EMAIL PROTECTED]wrote: Thank :) Although give me 10 minutes or so to fix something stupid I did before doing a checkout. Regards, ~ Simon On Thu, Aug 28, 2008 at 7:16 PM, Hazem Saleh [EMAIL PROTECTED] wrote: Thank you Simon. I will join this soon. On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Bruno, So far my planing was: sequential 1. Create all new API classes: done 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in their body when they aren't abstract: in progress and I already found some strange stuff that I might raise on the EG group discussions as for why Application.getResourceHandler isn't abstract while all other get handler methods are: in progress *** At that point, IMPL will no longer compile *** 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment in their body *** Everything should compile but don't work at all *** parallel 4. Modify the build plugin to include jsf 2.0 changes 5. Implement the API changes 6. Implement the IMPL changes 7. Implement the JS library I would really like to use Facelets code when required, but we'll have to make sure it's alright with legal discuss first I think, I'm not well versed enough in this kind of very specific issues. It's a very high level roadmap, We should probably use much finer granularity for point 5 to 7, but I'm not there yet. Regards, ~ Simon On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda [EMAIL PROTECTED]wrote: I am willing (as always) to contribute as much as my time permits to the JSF 2.0 implementation. I tried to find in the list what is going to be the big picture, the roadmap to have a JSF 2.0 implementation. Do we have something like that? How are we going to integrate Facelets, for instance? (good that is now under ASL!). What part are you developing at the moment? Thanks! Bruno 2008/8/28 Matthias Wessendorf [EMAIL PROTECTED] On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Simon, On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching [EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. As mentioned by other people, there was a vote about this a while back . Why did I create it just now? Simply because my company agreed to provide some resource to help with the implementation and we were ready to get started. One might ask here for a CCLA ;-) We did that for Oracle way back, and update once in a while all the contributors, that have signed the iCLA. Yeah, but Fujistu signed a CCLA already when I became commiter, so that's a non issue as well. good. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. To be honest, I find this irrelevant, it's a branch, not a trunk and I'll most likely do some branch merging when core 1.2.x get release and the plugin might have to change a little to support jsfVersion 2.0. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. I see even less relevance in that statement. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. The code was coded just yesterday by me and is not much at all, creating missing classes for the JavaDoc change log is in no matter a large amount in term of complexity. Also since I was the only author of it (my teammates will wait until I have added the
Re: JSF2.0 implementation
Thank you Simon On Fri, Aug 29, 2008 at 2:53 AM, Simon Lessard [EMAIL PROTECTED]wrote: Ok, The branch is now compiling and TODOs of the following format were placed in the newly created methods : // TODO: JSF 2.0 #xx We also created a JIRA ticket of every of those TODOs, so if you feel like trying one, you can add a comment in JIRA saying that you're taking the ticker. Before taking a ticket, make sure that no one else is currently working on it to prevent clashes. The next step on my side is to add more TODOs for the updated methods and create a JIRA ticket for them, then I'll get to coding myself. Thanks, ~ Simon On Thu, Aug 28, 2008 at 7:19 PM, Simon Lessard [EMAIL PROTECTED]wrote: Thank :) Although give me 10 minutes or so to fix something stupid I did before doing a checkout. Regards, ~ Simon On Thu, Aug 28, 2008 at 7:16 PM, Hazem Saleh [EMAIL PROTECTED] wrote: Thank you Simon. I will join this soon. On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Bruno, So far my planing was: sequential 1. Create all new API classes: done 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in their body when they aren't abstract: in progress and I already found some strange stuff that I might raise on the EG group discussions as for why Application.getResourceHandler isn't abstract while all other get handler methods are: in progress *** At that point, IMPL will no longer compile *** 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment in their body *** Everything should compile but don't work at all *** parallel 4. Modify the build plugin to include jsf 2.0 changes 5. Implement the API changes 6. Implement the IMPL changes 7. Implement the JS library I would really like to use Facelets code when required, but we'll have to make sure it's alright with legal discuss first I think, I'm not well versed enough in this kind of very specific issues. It's a very high level roadmap, We should probably use much finer granularity for point 5 to 7, but I'm not there yet. Regards, ~ Simon On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda [EMAIL PROTECTED]wrote: I am willing (as always) to contribute as much as my time permits to the JSF 2.0 implementation. I tried to find in the list what is going to be the big picture, the roadmap to have a JSF 2.0 implementation. Do we have something like that? How are we going to integrate Facelets, for instance? (good that is now under ASL!). What part are you developing at the moment? Thanks! Bruno 2008/8/28 Matthias Wessendorf [EMAIL PROTECTED] On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Simon, On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching [EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. As mentioned by other people, there was a vote about this a while back . Why did I create it just now? Simply because my company agreed to provide some resource to help with the implementation and we were ready to get started. One might ask here for a CCLA ;-) We did that for Oracle way back, and update once in a while all the contributors, that have signed the iCLA. Yeah, but Fujistu signed a CCLA already when I became commiter, so that's a non issue as well. good. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. To be honest, I find this irrelevant, it's a branch, not a trunk and I'll most likely do some branch merging when core 1.2.x get release and the plugin might have to change a little to support jsfVersion 2.0. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. I see even less relevance in that statement. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. The code was coded just yesterday by me and is not much at all, creating missing classes for the JavaDoc change log is in no matter a large amount in term of
[jira] Created: (MYFACES-1949) Apply myfaces-builder-plugin generation for myfaces core 1.2.x and 2.0.x
Apply myfaces-builder-plugin generation for myfaces core 1.2.x and 2.0.x Key: MYFACES-1949 URL: https://issues.apache.org/jira/browse/MYFACES-1949 Project: MyFaces Core Issue Type: Improvement Components: JSR-252, JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Actually, myfaces-builder-plugin is used on myfaces core 1.2 just to create component classes, but the remaining stuff is generated by myfaces-faces-plugin. It was suggested to do this before in order to avoid introduce bugs in this process, but tomahawk core 1.2 has tested the pending tasks (tag class generation, faces-config.xml and tld generation for 1.2) But after the creation of jsf 2.0 branch it could be good to enhance this now. The only thing that must be into account is take care of the generation of HtmlColumnTag (needs some custom code on the template used). My plan is do this after myfaces core 1.2.4 and apply on both branches (1.2.x and 2.0.x) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JSF2.0 implementation
On Thu, Aug 28, 2008 at 6:55 PM, Hazem Saleh [EMAIL PROTECTED] wrote: Thank you Simon On Fri, Aug 29, 2008 at 2:53 AM, Simon Lessard [EMAIL PROTECTED]wrote: Ok, The branch is now compiling and TODOs of the following format were placed in the newly created methods : // TODO: JSF 2.0 #xx We also created a JIRA ticket of every of those TODOs, so if you feel like trying one, you can add a comment in JIRA saying that you're taking the ticker. Before taking a ticket, make sure that no one else is currently working on it to prevent clashes. The next step on my side is to add more TODOs for the updated methods and create a JIRA ticket for them, then I'll get to coding myself. Thanks, ~ Simon On Thu, Aug 28, 2008 at 7:19 PM, Simon Lessard [EMAIL PROTECTED] wrote: Thank :) Although give me 10 minutes or so to fix something stupid I did before doing a checkout. Regards, ~ Simon On Thu, Aug 28, 2008 at 7:16 PM, Hazem Saleh [EMAIL PROTECTED] wrote: Thank you Simon. I will join this soon. On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Bruno, So far my planing was: sequential 1. Create all new API classes: done 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in their body when they aren't abstract: in progress and I already found some strange stuff that I might raise on the EG group discussions as for why Application.getResourceHandler isn't abstract while all other get handler methods are: in progress *** At that point, IMPL will no longer compile *** 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment in their body *** Everything should compile but don't work at all *** parallel 4. Modify the build plugin to include jsf 2.0 changes 5. Implement the API changes 6. Implement the IMPL changes 7. Implement the JS library I would really like to use Facelets code when required, but we'll have to make sure it's alright with legal discuss first I think, I'm not well versed enough in this kind of very specific issues. It's a very high level roadmap, We should probably use much finer granularity for point 5 to 7, but I'm not there yet. Regards, ~ Simon On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda [EMAIL PROTECTED]wrote: I am willing (as always) to contribute as much as my time permits to the JSF 2.0 implementation. I tried to find in the list what is going to be the big picture, the roadmap to have a JSF 2.0 implementation. Do we have something like that? How are we going to integrate Facelets, for instance? (good that is now under ASL!). What part are you developing at the moment? Thanks! Bruno 2008/8/28 Matthias Wessendorf [EMAIL PROTECTED] On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Simon, On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching [EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. As mentioned by other people, there was a vote about this a while back . Why did I create it just now? Simply because my company agreed to provide some resource to help with the implementation and we were ready to get started. One might ask here for a CCLA ;-) We did that for Oracle way back, and update once in a while all the contributors, that have signed the iCLA. Yeah, but Fujistu signed a CCLA already when I became commiter, so that's a non issue as well. good. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. To be honest, I find this irrelevant, it's a branch, not a trunk and I'll most likely do some branch merging when core 1.2.x get release and the plugin might have to change a little to support jsfVersion 2.0. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. I see even less relevance in that statement. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. The code was coded just yesterday by me and is not much at all, creating missing classes
DateTimeConverter's patterns
I had a couple questions on org.apache.myfaces.trinidad.convert.DateTimeConverter._doLenientParse(). This method creates a set of patterns to match against the user provided input string. Of course, we start with the format associated with the current locale. But to make our converter more friendly, we also try with 3 other patterns for convenience (TRINIDAD-859). (a) The patterns variable is of type HashSet. Set (and its implementation HashSet) do not provide any guarantee of iteration. Do we not care about the order in which we try to make matches? Note that in the client validation code, we use an array which imposes an order. (b) Also, the 3 static strings do not take into consideration the locale. So for e.g. no matter if the locale is en_us (USA) or en (Europe) the first static pattern is MM dd yy. This seems confusing. Any feedback would be useful. Thanks Anita
Re: JSF2.0 implementation
Sent from my iPod. Am 29.08.2008 um 01:53 schrieb Simon Lessard [EMAIL PROTECTED] : Ok, The branch is now compiling and TODOs of the following format were placed in the newly created methods : // TODO: JSF 2.0 #xx We also created a JIRA ticket of every of those TODOs, so if you feel like trying one, you can add a comment in JIRA saying that you're taking the ticker. Before taking a ticket, make sure that no one else is currently working on it to prevent clashes. That's why you can assign tickets. The next step on my side is to add more TODOs for the updated methods and create a JIRA ticket for them, then I'll get to coding myself. Thanks, ~ Simon On Thu, Aug 28, 2008 at 7:19 PM, Simon Lessard [EMAIL PROTECTED] wrote: Thank :) Although give me 10 minutes or so to fix something stupid I did before doing a checkout. Regards, ~ Simon On Thu, Aug 28, 2008 at 7:16 PM, Hazem Saleh [EMAIL PROTECTED] wrote: Thank you Simon. I will join this soon. On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Bruno, So far my planing was: sequential 1. Create all new API classes: done 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in their body when they aren't abstract: in progress and I already found some strange stuff that I might raise on the EG group discussions as for why Application.getResourceHandler isn't abstract while all other get handler methods are: in progress *** At that point, IMPL will no longer compile *** 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment in their body *** Everything should compile but don't work at all *** parallel 4. Modify the build plugin to include jsf 2.0 changes 5. Implement the API changes 6. Implement the IMPL changes 7. Implement the JS library I would really like to use Facelets code when required, but we'll have to make sure it's alright with legal discuss first I think, I'm not well versed enough in this kind of very specific issues. It's a very high level roadmap, We should probably use much finer granularity for point 5 to 7, but I'm not there yet. Regards, ~ Simon On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda [EMAIL PROTECTED] wrote: I am willing (as always) to contribute as much as my time permits to the JSF 2.0 implementation. I tried to find in the list what is going to be the big picture, the roadmap to have a JSF 2.0 implementation. Do we have something like that? How are we going to integrate Facelets, for instance? (good that is now under ASL!). What part are you developing at the moment? Thanks! Bruno 2008/8/28 Matthias Wessendorf [EMAIL PROTECTED] On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Simon, On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching [EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. As mentioned by other people, there was a vote about this a while back . Why did I create it just now? Simply because my company agreed to provide some resource to help with the implementation and we were ready to get started. One might ask here for a CCLA ;-) We did that for Oracle way back, and update once in a while all the contributors, that have signed the iCLA. Yeah, but Fujistu signed a CCLA already when I became commiter, so that's a non issue as well. good. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. To be honest, I find this irrelevant, it's a branch, not a trunk and I'll most likely do some branch merging when core 1.2.x get release and the plugin might have to change a little to support jsfVersion 2.0. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. I see even less relevance in that statement. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. The code was coded just yesterday by me and is not much at all, creating missing classes for the JavaDoc change log is in no matter a large amount in term of
Re: JSF2.0 implementation
good point leo. When needed we can create it, k? Sent from my iPod. Am 29.08.2008 um 02:11 schrieb Leonardo Uribe [EMAIL PROTECTED]: On Thu, Aug 28, 2008 at 6:55 PM, Hazem Saleh [EMAIL PROTECTED] wrote: Thank you Simon On Fri, Aug 29, 2008 at 2:53 AM, Simon Lessard [EMAIL PROTECTED] wrote: Ok, The branch is now compiling and TODOs of the following format were placed in the newly created methods : // TODO: JSF 2.0 #xx We also created a JIRA ticket of every of those TODOs, so if you feel like trying one, you can add a comment in JIRA saying that you're taking the ticker. Before taking a ticket, make sure that no one else is currently working on it to prevent clashes. The next step on my side is to add more TODOs for the updated methods and create a JIRA ticket for them, then I'll get to coding myself. Thanks, ~ Simon On Thu, Aug 28, 2008 at 7:19 PM, Simon Lessard [EMAIL PROTECTED] wrote: Thank :) Although give me 10 minutes or so to fix something stupid I did before doing a checkout. Regards, ~ Simon On Thu, Aug 28, 2008 at 7:16 PM, Hazem Saleh [EMAIL PROTECTED] wrote: Thank you Simon. I will join this soon. On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Bruno, So far my planing was: sequential 1. Create all new API classes: done 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in their body when they aren't abstract: in progress and I already found some strange stuff that I might raise on the EG group discussions as for why Application.getResourceHandler isn't abstract while all other get handler methods are: in progress *** At that point, IMPL will no longer compile *** 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment in their body *** Everything should compile but don't work at all *** parallel 4. Modify the build plugin to include jsf 2.0 changes 5. Implement the API changes 6. Implement the IMPL changes 7. Implement the JS library I would really like to use Facelets code when required, but we'll have to make sure it's alright with legal discuss first I think, I'm not well versed enough in this kind of very specific issues. It's a very high level roadmap, We should probably use much finer granularity for point 5 to 7, but I'm not there yet. Regards, ~ Simon On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda [EMAIL PROTECTED] wrote: I am willing (as always) to contribute as much as my time permits to the JSF 2.0 implementation. I tried to find in the list what is going to be the big picture, the roadmap to have a JSF 2.0 implementation. Do we have something like that? How are we going to integrate Facelets, for instance? (good that is now under ASL!). What part are you developing at the moment? Thanks! Bruno 2008/8/28 Matthias Wessendorf [EMAIL PROTECTED] On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi Simon, On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching [EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. As mentioned by other people, there was a vote about this a while back . Why did I create it just now? Simply because my company agreed to provide some resource to help with the implementation and we were ready to get started. One might ask here for a CCLA ;-) We did that for Oracle way back, and update once in a while all the contributors, that have signed the iCLA. Yeah, but Fujistu signed a CCLA already when I became commiter, so that's a non issue as well. good. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. To be honest, I find this irrelevant, it's a branch, not a trunk and I'll most likely do some branch merging when core 1.2.x get release and the plugin might have to change a little to support jsfVersion 2.0. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. I see even less relevance in that statement. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA.
