Re: svn commit: r613743 - in /myfaces/core/trunk_1.2.x: api/pom.xml build/pom.xml impl/pom.xml pom.xml
[EMAIL PROTECTED] schrieb: -removed redundant versions as well... plugin -groupIdorg.apache.myfaces.trinidadbuild/groupId -artifactIdmaven-faces-plugin/artifactId -version1.2.6-SNAPSHOT/version +groupIdorg.apache.myfaces.buildtools/groupId +artifactIdmyfaces-faces-plugin/artifactId Why is there no version tag here? A plugin with no version specified == unpredictable builds. --- myfaces/core/trunk_1.2.x/pom.xml (original) +++ myfaces/core/trunk_1.2.x/pom.xml Sun Jan 20 19:50:35 2008 @@ -64,9 +64,9 @@ pluginManagement plugins plugin - groupIdorg.apache.myfaces.trinidadbuild/groupId - artifactIdmaven-faces-plugin/artifactId - version1.2.6-SNAPSHOT/version + groupIdorg.apache.myfaces.buildtools/groupId + artifactIdmyfaces-faces-plugin/artifactId + version1.0.0-SNAPSHOT/version That looks better to me... Regards, Simon
[jira] Created: (TRINIDAD-911) js centering bug in tr:panelPopup
js centering bug in tr:panelPopup
-
Key: TRINIDAD-911
URL: https://issues.apache.org/jira/browse/TRINIDAD-911
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Renzo Tomaselli
Hi, in method TrPanelPopup._centerOnScreen() the window height is computed for
IE through document.body.clientHeight.
This provides document height instead of window height, in case of IE 6+ in
strict mode.
The final result is an up-shifted panel, even beyond the top in case of panels
higher than current document.
Using document.documentElement.clientHeight does the right job, if returned
value is not 0 (strict). Otherwise we are in quirks mode, thus use
document.body.clientHeight.
TrPanelPopup._centerOnScreen() should contain something like:
...
if (this._isIE())
{
var width = document.documentElement.clientWidth; // strict
if (width == 0)
width = document.body.clientWidth; // quirks
loc = document.body.scrollLeft + ((width - element.clientWidth) / 2) -
parentPos.x;
element.style.left = loc + px;
var heigth = document.documentElement.clientHeight; // strict
if (heigth == 0)
heigth = document.body.clientHeight;// quirks
loc = document.body.scrollTop + ((height - element.clientHeight) / 2) -
parentPos.y;
element.style.top = loc + px;
}
...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Reg:Html code not working with .jspx page
I am using xmlns:trh=http://myfaces.apache.org/trinidad/html;
and also using xmlns:h=http://java.sun.com/jsf/html; in my
.jspx page. The html code written is working fine stand alone
in .html file but the same code not working in .jspx file.
Code for that is given below.
script type=text/javascript
function formatOnKeyPress(element)
{
var
value=element.value;
var limit = new
Array(6,2);
var c =
String.fromCharCode(window.event.keyCode);
value =
value.replace(/^\s+/, ).replace(/\s+$/, );
if
(/\d/.test(c)amp;amp;(/\./.test(value)?/^.*\.\d?$/.test(value):(!value||value.match(/\d/g).lengthlt;6)))
{
value=
/^[^\.]*$/.test(value)?/^.*\,?\d{3}$/.test(value)?value+,:value:value;
element.value=value;
return true;
}else if
(/[\.\,]/.test(c)amp;amp;!/\./.test(value)){
return true;
}else{
return false;
}
}
/script
h:inputText id=txtBalance maxlength=10
value=#{MyBean.adjustBal}
styleClass=InputText onkeypress=return formatOnKeyPress(this);
/
reply as soon as possible.
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
image/gif
[jira] Created: (MYFACES-1806) The attribute forceID=true is not working in included subwie
The attribute forceID=true is not working in included subwie -- Key: MYFACES-1806 URL: https://issues.apache.org/jira/browse/MYFACES-1806 Project: MyFaces Core Issue Type: Bug Reporter: Ertan Toker -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Tomahawk's compatibility matrix is out of date!
Tomahawk's compatibility matrix [1] is out of date. Specifically the Tomahawk 1.1.6 row and the MyFaces 1.2.0 column. I know MyFaces 1.2.1 is in the works, so whomever updates the matrix could also add this column. I am not sure of the compatibility data so did not update the table. Paul Spencer [1] http://wiki.apache.org/myfaces/CompatibilityMatrix
[jira] Created: (MYFACES-1807) The attribute forceID=true is not working in included subviews
The attribute forceID=true is not working in included subviews Key: MYFACES-1807 URL: https://issues.apache.org/jira/browse/MYFACES-1807 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.1 Environment: Ubuntu 7.10, JDK 1.6.03, Apache Tomcat 6.0.14, Apache Tomahawk 1.1.6 Reporter: Ertan Toker HI, i find out, that the forceId=true attribute is not working with included subviews in MyFaces 1.2.1 SNAPSHOTS. Is works fine with MyFaces 1.2.0. SourceCode: login.jsp t:documentBody !-- Begin Header -- jsp:include page=/misc/header.jsp / !-- End Header -- !-- Begin HeaderMenu-- jsp:include page=/misc/headerMenu.jsp / !-- End HeaderMenu-- !-- Begin Content -- t:div forceId=true id=content jsp:include page=/misc/loginFragment.jsp / !-- Begin Links -- jsp:include page=/misc/links.jsp / !-- End Links-- t:div style=clear: both; f:verbatimnbsp;/f:verbatim /t:div /t:div !-- End Content -- !-- Begin Footer -- jsp:include page=/misc/footer.jsp / !-- End Footer -- /t:documentBody Source Code header.jsp: %@ taglib uri=http://java.sun.com/jsf/core; prefix=f % %@ taglib uri=http://java.sun.com/jsf/html; prefix=h % %@ taglib uri=http://myfaces.apache.org/tomahawk; prefix=t % f:subview id=header_view t:div forceId=true id=header f:verbatimh1CV Creator V1.0/h1 h2Free CV Creator Application/h2 /f:verbatim /t:div /f:subview Generated HTML Code with MyFaces 1.2.0: htmlhead titleMyApplication Title/title link rel=stylesheet type=text/css href=/myapplication/css/default.css //headbody !-- Begin Header -- div id=headerh1MyApplication/h1 h2MyApplication/h2 /div !-- End Header -- Generated HTML Code with MyFaces 1.2.1-SNAPSHOTS: htmlhead titleMyApplication Title/title link rel=stylesheet type=text/css href=/myapplication/css/default.css //headbody !-- Begin Header -- div id=headerj_id_1h1MyApplication/h1 h2MyApplication/h2 /div !-- End Header -- In the version 1.2.0 the ID of the div tag is header and with the SNAPSHOTS it is headerj_id_1. Regards ETO -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r613743 - in /myfaces/core/trunk_1.2.x: api/pom.xml build/pom.xml impl/pom.xml pom.xml
On Jan 21, 2008 12:03 AM, Simon Kitching [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schrieb: -removed redundant versions as well... plugin -groupIdorg.apache.myfaces.trinidadbuild/groupId -artifactIdmaven-faces-plugin/artifactId -version1.2.6-SNAPSHOT/version +groupIdorg.apache.myfaces.buildtools/groupId +artifactIdmyfaces-faces-plugin/artifactId Why is there no version tag here? because this is inheriting the version from the plugin-mgmt. A plugin with no version specified == unpredictable builds. --- myfaces/core/trunk_1.2.x/pom.xml (original) +++ myfaces/core/trunk_1.2.x/pom.xml Sun Jan 20 19:50:35 2008 @@ -64,9 +64,9 @@ pluginManagement plugins plugin - groupIdorg.apache.myfaces.trinidadbuild/groupId - artifactIdmaven-faces-plugin/artifactId - version1.2.6-SNAPSHOT/version + groupIdorg.apache.myfaces.buildtools/groupId + artifactIdmyfaces-faces-plugin/artifactId + version1.0.0-SNAPSHOT/version That looks better to me... from this one.. Regards, Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: archetypes... release
ah, right :-) sure! On Jan 21, 2008 1:25 AM, Martin Marinschek [EMAIL PROTECTED] wrote: well, now we can also wait for 1.2.1 release, right? regards, Martin On 1/21/08, Matthias Wessendorf [EMAIL PROTECTED] wrote: hi, are there still some open items regarding the archetypes`? If not, I'd like to run the release, that they finally :-) get out to the world. -M -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [VOTE] Release Tobago 1.0.14
+1 On Jan 20, 2008 12:10 PM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello, I would like to release Tobago 1.0.14, The 1.0.x series has only maintenance focus. This release contains only a few changes. For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12312878 The version is available at the staging location and the revision number of the release is 613635 and tagged as tobago-1.0.14. Staging distribution: http://people.apache.org/~bommel/repo/ Staging repository: http://people.apache.org/~bommel/repo/ Regards Bernd The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: maven-build-tools notice and license files
hrm...
yeah, well.
should we add this ?
I think yes. Even it is ugly.
-M
On Jan 20, 2008 11:52 PM, Simon Kitching [EMAIL PROTECTED] wrote:
Yep, notice-in-javadoc-jar needs to be fixed too.
The apache commons parent pom does it like this:
plugin
!--
- Copy LICENSE.txt and NOTICE.txt so that they are included
- in the -javadoc jar file for the component.
--
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idjavadoc.resources/id
phasegenerate-sources/phase
goals
goalrun/goal
/goals
configuration
tasks
copy todir=${project.build.directory}/apidocs/META-INF
fileset dir=${basedir}
include name=LICENSE.txt /
include name=NOTICE.txt /
/fileset
/copy
/tasks
/configuration
/execution
/executions
/plugin
See:
http://svn.apache.org/repos/asf/commons/proper/commons-parent/trunk/pom.xml
It would definitely be nicer to have a proper maven plugin to do this - but
the apache-jar-resources-plugin has other undesirable side-effects.
Regards,
Simon
Matthias Wessendorf [EMAIL PROTECTED] schrieb:
Simon,
as I expected the release causes some issues.
The blah-javadoc.jar files don't have the notice and license files
included.
We (when incubating trinidad) had had this issue in the past, and
as a workaround, we used the apache-jar-resources-bundle.
-Matthias
On Jan 20, 2008 10:08 AM, simon [EMAIL PROTECTED] wrote:
On Sun, 2008-01-20 at 19:00 +0100, simon wrote:
Ok, tried - but don't have commit permissions to this project it seems:
Please forget that. I had checked this dir out using an http: url, not
https. So of course could not commit. Done now.
I have also updated the parent reference to the recently released
version 5.
Regards, Simon
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [VOTE] Release Tobago 1.0.14
+1 On Jan 21, 2008 8:01 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: +1 On Jan 20, 2008 12:10 PM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello, I would like to release Tobago 1.0.14, The 1.0.x series has only maintenance focus. This release contains only a few changes. For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12312878 The version is available at the staging location and the revision number of the release is 613635 and tagged as tobago-1.0.14. Staging distribution: http://people.apache.org/~bommel/repo/http://people.apache.org/%7Ebommel/repo/ Staging repository: http://people.apache.org/~bommel/repo/http://people.apache.org/%7Ebommel/repo/ Regards Bernd The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Grant Smith
[jira] Commented: (TOBAGO-539) Accelerator keys don't work properly in tabGroup
[ https://issues.apache.org/jira/browse/TOBAGO-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561057#action_12561057 ] Helmut Swaczinna commented on TOBAGO-539: - I've been able to locate the cause of this problem (but not able to fix it). In tabgroup.js in method removeRelatedAcceleratorKey() must the dummy accelerator key helper element for IE (added in Tobago.AcceleratorKey()) be removed. Accelerator keys don't work properly in tabGroup Key: TOBAGO-539 URL: https://issues.apache.org/jira/browse/TOBAGO-539 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 1.0.12, 1.0.13 Environment: IE 6/7 Reporter: Helmut Swaczinna Switching the tabs by accelerator key (alt + key) doesn't work properly with switchType=reloadTab. You have the push the key twice to switch to the tab. In this example you have to push the alt + b key always twice. f:view tc:page id=tabsPage width=200px height=100px tc:tabGroup switchType=reloadTab tc:tab id=tab1 label=T_ab1 tc:out value=Tab1/ /tc:tab tc:tab id=tab2 label=Ta_b2 tc:out value=Tab2/ /tc:tab /tc:tabGroup /tc:page /f:view -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: maven-build-tools notice and license files
No luck with that
can you give it a shot?
-M
On Jan 21, 2008 8:05 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
hrm...
yeah, well.
should we add this ?
I think yes. Even it is ugly.
-M
On Jan 20, 2008 11:52 PM, Simon Kitching [EMAIL PROTECTED] wrote:
Yep, notice-in-javadoc-jar needs to be fixed too.
The apache commons parent pom does it like this:
plugin
!--
- Copy LICENSE.txt and NOTICE.txt so that they are included
- in the -javadoc jar file for the component.
--
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idjavadoc.resources/id
phasegenerate-sources/phase
goals
goalrun/goal
/goals
configuration
tasks
copy todir=${project.build.directory}/apidocs/META-INF
fileset dir=${basedir}
include name=LICENSE.txt /
include name=NOTICE.txt /
/fileset
/copy
/tasks
/configuration
/execution
/executions
/plugin
See:
http://svn.apache.org/repos/asf/commons/proper/commons-parent/trunk/pom.xml
It would definitely be nicer to have a proper maven plugin to do this - but
the apache-jar-resources-plugin has other undesirable side-effects.
Regards,
Simon
Matthias Wessendorf [EMAIL PROTECTED] schrieb:
Simon,
as I expected the release causes some issues.
The blah-javadoc.jar files don't have the notice and license files
included.
We (when incubating trinidad) had had this issue in the past, and
as a workaround, we used the apache-jar-resources-bundle.
-Matthias
On Jan 20, 2008 10:08 AM, simon [EMAIL PROTECTED] wrote:
On Sun, 2008-01-20 at 19:00 +0100, simon wrote:
Ok, tried - but don't have commit permissions to this project it
seems:
Please forget that. I had checked this dir out using an http: url, not
https. So of course could not commit. Done now.
I have also updated the parent reference to the recently released
version 5.
Regards, Simon
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: svn commit: r613797 - /myfaces/tobago/trunk/pom.xml
-sunjsf12.version1.2_04-p02/sunjsf12.version +sunjsf12.version1.2_07/sunjsf12.version yes. that is more stable. -M facelets.version1.1.14/facelets.version jetty.version6.1.7/jetty.version common-io.version1.1/common-io.version -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [MyFaces 1.2.1] question on trunk and tag
On Jan 20, 2008 9:50 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, two questions. 1) There is a 1.2.1 TAG: http://svn.apache.org/repos/asf/myfaces/core/tags/1_2_1_RC/ that uses Trinidad's 1.2.6 plugins. Why? There was no release of that. Currently there is one on the vote (ends today) so, to me it is not clear if the used maven-faces-plugin is *really* this particular one. this problem is solved now. The 1.2.6 plugins are mirrored world-wide 2) The trunk says 1.2.1-SNAPSHOT. In case we use the above mentioned TAG, shouldn't it say 1.2.2-SNAPSHOT already? Thanks! Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
perhaps this 1.2.2 vs. 1.2.1 should haven been discussed here on the mailing list. opening a discussion after done some work is always not the best way :-( -M On Jan 21, 2008 12:18 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi In a discussion on dev list, I have noted this comment: Simon I guess the other solution is to just do nothing until the *real* 1.2.1 release goes out, overwriting the bad files. I believe that is expected to happen in the next week or so. But I feel a little uncomfortable about that, and at the least we would need to notify the user list. +1 in case they still were online, we just could override them. But... as a matter of fact, they aren't (as mentioned before): -http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/myfaces/core/myfaces-impl/ -http://repo1.maven.org/maven2/org/apache/myfaces/core/myfaces-impl/ -http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/myfaces/core/myfaces-impl/ (btw. same is true for API as well, NO 1.2.1 online). Wendy IMO there should not be a real 1.2.1 release now -- we should move on to 1.2.2 to avoid confusion in case anyone has downloaded these bad jars. hu? the next logical step would be a 1.2.1, IMO. we would confuse the people much more in just providing a 1.2.2 now, IMO. I am pretty sure, that a 1.2.2 will even confuse our community a bit. So how to manage not confusing others? Like vendors, that plan to provide support for MyFaces ? I really think it is not a good a idea to release a 1.2.2 after 1.2.0. The bad artifacts were available about 2 weeks, until it was removed from main repo, so there is a possible confusion if anyone downloaded the bad artifacts. (myfaces-impl 1.2.1 artifacts and myfaces-core-project related artifacts). you'd get a fresh JAR... regards Leonardo Uribe -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
Yes, I agree with you forget the work done at this time My vote for a 1.2.1 release is +1 (two weeks is not a big time). Any objections for release myfaces as 1.2.1?
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
On Jan 21, 2008 1:18 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: the next logical step would be a 1.2.1, IMO. we would confuse the people much more in just providing a 1.2.2 now, IMO. I am pretty sure, that a 1.2.2 will even confuse our community a bit. So how to manage not confusing others? Like vendors, that plan to provide support for MyFaces ? I really think it is not a good a idea to release a 1.2.2 after 1.2.0. I don't agree. Tomcat skips versions occasionally with no ill effects, and so does Struts. (Occasionally someone asks what happened to x.x.x on the mailing list but that's all.) -- Wendy
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
I am not fighting to death for a 1.2.1 after 1.2.0 ;-) I more care about that things like what do we want 1.2.2 because issues with 1.2.1 are discussed on the mailing list, *before* putting a serious amount of work to it. Personally I think that a 1.2.2 is just a string ;-) but a little bit different than the 1.2.1 string. That's all. -Matthias On Jan 21, 2008 12:33 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: Yes, I agree with you forget the work done at this time My vote for a 1.2.1 release is +1 (two weeks is not a big time). Any objections for release myfaces as 1.2.1? -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
I don't agree. Tomcat skips versions occasionally with no ill effects, and so does Struts. (Occasionally someone asks what happened to x.x.x on the mailing list but that's all.) but the reason for skipping a version number would be discussed before on the ml. I don't think that they do the new version number out of the blue, right :-) -Matthias -- Wendy -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
So we agree on 1.2.2?
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
If something was publicly released as 1.2.1 already, then -- even if it was pulled -- please do not release 1.2.1 again. Skipping a version number might cause some questions on the list. However, reusing a version number will result in the end user not knowing if they have the good version or the bad version, nor will anyone who tries to help them debug issues. On Jan 21, 2008 4:00 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: So we agree on 1.2.2?
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
On Jan 21, 2008 1:08 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: If something was publicly released as 1.2.1 already, then -- even if it was pulled -- please do not release 1.2.1 again. it wasn't released. Just the impl jars made it to public repo. which is (from the effect) close to a release ;-) -M Skipping a version number might cause some questions on the list. However, reusing a version number will result in the end user not knowing if they have the good version or the bad version, nor will anyone who tries to help them debug issues. On Jan 21, 2008 4:00 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: So we agree on 1.2.2? -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
On Jan 21, 2008 4:10 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Jan 21, 2008 1:08 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: If something was publicly released as 1.2.1 already, then -- even if it was pulled -- please do not release 1.2.1 again. it wasn't released. Just the impl jars made it to public repo. which is (from the effect) close to a release ;-) Sorry. I'll be more careful in my wording: If something was publicly made available as 1.2.1 already, then -- even if it was pulled -- please do not make something else publicly available as 1.2.1 again unless it is identical to the first 1.2.1.
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
Because artifacts where published, even if that was not the intent, the version number should be consider used. Paul Spencer Matthias Wessendorf wrote: On Jan 21, 2008 1:08 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: If something was publicly released as 1.2.1 already, then -- even if it was pulled -- please do not release 1.2.1 again. it wasn't released. Just the impl jars made it to public repo. which is (from the effect) close to a release ;-) -M Skipping a version number might cause some questions on the list. However, reusing a version number will result in the end user not knowing if they have the good version or the bad version, nor will anyone who tries to help them debug issues. On Jan 21, 2008 4:00 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: So we agree on 1.2.2?
[jira] Created: (TRINIDAD-912) PPR error with XHTML JSPs
PPR error with XHTML JSPs
-
Key: TRINIDAD-912
URL: https://issues.apache.org/jira/browse/TRINIDAD-912
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.5-core
Environment: Windows XP, Tomcat 6.0.14, JSF 1.2 RI
Reporter: Mathias Walter
I'm using XHTML inside JSPs. If I include the XML processing instruction ?xml
version=1.0 encoding=iso-8859-1? at the top of the page, partial triggers
won't work.
Firebug displays:
Invalid PPR response. The response-headers were:\nServer:
Apache-Coyote/1.1\nX-Powered-By: JSF/1.2\nCon...
and the PPR result is:
?xml version=1.0 encoding=ISO-8859-1 ?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
?xml version=1.0 ?
?Tr-XHR-Response-Type ?
Conclusion: PPR should not add the XML processing instruction if it's already
present.
How to reproduce?
Create a jsp file with the following content:
?xml version=1.0 encoding=ISO-8859-1 ?
[EMAIL PROTECTED] uri=http://java.sun.com/jsf/core; prefix=f%
[EMAIL PROTECTED] uri=http://java.sun.com/jsf/html; prefix=h%
[EMAIL PROTECTED] uri=http://myfaces.apache.org/trinidad; prefix=tr%
[EMAIL PROTECTED] language=java contentType=text/html; charset=ISO-8859-1
pageEncoding=ISO-8859-1%
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
f:view
html xmlns=http://www.w3.org/1999/xhtml;
head/
body
tr:form
tr:panelGroupLayout partialTriggers=test
tr:commandLink id=test actionListener=#{cm.click}
text=Click Me! partialSubmit=true/
/tr:panelGroupLayout
/tr:form
/body
/html
/f:view
The backing bean method does nothing.
put the following mapping inside web.xml:
servlet-mapping
servlet-namefaces/servlet-name
url-pattern*.jsf/url-pattern
/servlet-mapping
Deploy and open .../test.jsf with FireFox. Click on the link and view the
output in FireBug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
I am all for 1.2.2 - if someone downloaded the 1.2.1, he'll be confused - releasing 1.2.2, we spare everyone the potential confusion. It is highly normal to skip a point-release, that's really not a problem, I would think. I thought that was already the outcome of the discussion on the dev-list, as I understood it. regards, Martin On Jan 21, 2008 10:31 PM, Paul Spencer [EMAIL PROTECTED] wrote: Because artifacts where published, even if that was not the intent, the version number should be consider used. Paul Spencer Matthias Wessendorf wrote: On Jan 21, 2008 1:08 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: If something was publicly released as 1.2.1 already, then -- even if it was pulled -- please do not release 1.2.1 again. it wasn't released. Just the impl jars made it to public repo. which is (from the effect) close to a release ;-) -M Skipping a version number might cause some questions on the list. However, reusing a version number will result in the end user not knowing if they have the good version or the bad version, nor will anyone who tries to help them debug issues. On Jan 21, 2008 4:00 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: So we agree on 1.2.2? -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
as of now, I am also fine with a 1.2.2; but I really noticed not a common agreement on using 1.2.2 IMO the 1.2.1 would be updated, by maven. (unless you run in offline mode, which is totally broken anyway) -Matthias On Jan 21, 2008 2:00 PM, Martin Marinschek [EMAIL PROTECTED] wrote: I am all for 1.2.2 - if someone downloaded the 1.2.1, he'll be confused - releasing 1.2.2, we spare everyone the potential confusion. It is highly normal to skip a point-release, that's really not a problem, I would think. I thought that was already the outcome of the discussion on the dev-list, as I understood it. regards, Martin On Jan 21, 2008 10:31 PM, Paul Spencer [EMAIL PROTECTED] wrote: Because artifacts where published, even if that was not the intent, the version number should be consider used. Paul Spencer Matthias Wessendorf wrote: On Jan 21, 2008 1:08 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: If something was publicly released as 1.2.1 already, then -- even if it was pulled -- please do not release 1.2.1 again. it wasn't released. Just the impl jars made it to public repo. which is (from the effect) close to a release ;-) -M Skipping a version number might cause some questions on the list. However, reusing a version number will result in the end user not knowing if they have the good version or the bad version, nor will anyone who tries to help them debug issues. On Jan 21, 2008 4:00 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: So we agree on 1.2.2? -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Commented: (MYFACES-1805) form stopped working after ajax request
[ https://issues.apache.org/jira/browse/MYFACES-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561146#action_12561146 ] Martin Marinschek commented on MYFACES-1805: Is this related to https://issues.apache.org/jira/browse/MYFACES-1804 ? regards, Martin form stopped working after ajax request --- Key: MYFACES-1805 URL: https://issues.apache.org/jira/browse/MYFACES-1805 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.5, 1.2.0 Reporter: Mario Ivankovits Fix For: 1.1.6-SNAPSHOT, 1.2.2-SNAPSHOT In a little bit complicated form using multiple PPR areas the datascroller attached to a datatable stopped working with InternetExplorer after the first ajax request. MyFaces always sent the current page again. It turned out that the code in oamSetHiddenInput is not fully compatible with InternetExplorer. The problem is that even after adding the element to the form using javascript the check for it (typeof form.elements[name]=='undefined') still returns undefined. After setting the id of the created element (beside of it's name) fixed this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
after removing ?xml version=1.0 encoding=ISO-8859-1 ? works On Jan 21, 2008 2:03 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: as of now, I am also fine with a 1.2.2; but I really noticed not a common agreement on using 1.2.2 IMO the 1.2.1 would be updated, by maven. (unless you run in offline mode, which is totally broken anyway) -Matthias On Jan 21, 2008 2:00 PM, Martin Marinschek [EMAIL PROTECTED] wrote: I am all for 1.2.2 - if someone downloaded the 1.2.1, he'll be confused - releasing 1.2.2, we spare everyone the potential confusion. It is highly normal to skip a point-release, that's really not a problem, I would think. I thought that was already the outcome of the discussion on the dev-list, as I understood it. regards, Martin On Jan 21, 2008 10:31 PM, Paul Spencer [EMAIL PROTECTED] wrote: Because artifacts where published, even if that was not the intent, the version number should be consider used. Paul Spencer Matthias Wessendorf wrote: On Jan 21, 2008 1:08 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: If something was publicly released as 1.2.1 already, then -- even if it was pulled -- please do not release 1.2.1 again. it wasn't released. Just the impl jars made it to public repo. which is (from the effect) close to a release ;-) -M Skipping a version number might cause some questions on the list. However, reusing a version number will result in the end user not knowing if they have the good version or the bad version, nor will anyone who tries to help them debug issues. On Jan 21, 2008 4:00 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: So we agree on 1.2.2? -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
Ok, so the general opinion now is 1.2.2, the community has decided.
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
whoops, belongs to another email :) On Jan 21, 2008 2:12 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: after removing ?xml version=1.0 encoding=ISO-8859-1 ? works On Jan 21, 2008 2:03 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: as of now, I am also fine with a 1.2.2; but I really noticed not a common agreement on using 1.2.2 IMO the 1.2.1 would be updated, by maven. (unless you run in offline mode, which is totally broken anyway) -Matthias On Jan 21, 2008 2:00 PM, Martin Marinschek [EMAIL PROTECTED] wrote: I am all for 1.2.2 - if someone downloaded the 1.2.1, he'll be confused - releasing 1.2.2, we spare everyone the potential confusion. It is highly normal to skip a point-release, that's really not a problem, I would think. I thought that was already the outcome of the discussion on the dev-list, as I understood it. regards, Martin On Jan 21, 2008 10:31 PM, Paul Spencer [EMAIL PROTECTED] wrote: Because artifacts where published, even if that was not the intent, the version number should be consider used. Paul Spencer Matthias Wessendorf wrote: On Jan 21, 2008 1:08 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: If something was publicly released as 1.2.1 already, then -- even if it was pulled -- please do not release 1.2.1 again. it wasn't released. Just the impl jars made it to public repo. which is (from the effect) close to a release ;-) -M Skipping a version number might cause some questions on the list. However, reusing a version number will result in the end user not knowing if they have the good version or the bad version, nor will anyone who tries to help them debug issues. On Jan 21, 2008 4:00 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: So we agree on 1.2.2? -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Resolved: (MYFACES-1781) Problem with required field and label attribute
[
https://issues.apache.org/jira/browse/MYFACES-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-1781.
-
Resolution: Duplicate
Fix Version/s: 1.2.2
Issue duplicated (see MYFACES-1729)
Problem with required field and label attribute
---
Key: MYFACES-1781
URL: https://issues.apache.org/jira/browse/MYFACES-1781
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.2.0
Environment: Tomcat 6, Facelets 1.1.14, ajax4jsf 1.0.5, jdk 1.5_06
Reporter: Ricard Moré
Fix For: 1.2.2
Hi,
I am testing MyFaces 1.2 implementation, but I think I found an issue with
required field validation.
I have a required message like this 'El campo {0} es obligatorio' in my
resourceBundle with label javax.faces.component.UIInput.REQUIRED.
In the h:inputText im tryng to substitute the {0} param with the label
attribute value.
The problem is that, if I use a label reference like
label=#{bundle['login.password']} the {0} is subtituted by a null value.
But if I use label=a or label=#{loginForm.passwordLabel} it works
fine. It seems that label attribute do not accept messages from
resourceBundle.
Sorry for my simple english... I hope you can understand the problem.
Regards,
Ricard
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
I am all for 1.2.2 - if someone downloaded the 1.2.1, he'll be confused - releasing 1.2.2, we spare everyone the potential confusion. It is highly normal to skip a point-release, that's really not a problem, I would think. I agree, +1 for 1.2.2 On Jan 22, 2008 12:20 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: whoops, belongs to another email :) On Jan 21, 2008 2:12 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: after removing ?xml version=1.0 encoding=ISO-8859-1 ? works On Jan 21, 2008 2:03 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: as of now, I am also fine with a 1.2.2; but I really noticed not a common agreement on using 1.2.2 IMO the 1.2.1 would be updated, by maven. (unless you run in offline mode, which is totally broken anyway) -Matthias On Jan 21, 2008 2:00 PM, Martin Marinschek [EMAIL PROTECTED] wrote: I am all for 1.2.2 - if someone downloaded the 1.2.1, he'll be confused - releasing 1.2.2, we spare everyone the potential confusion. It is highly normal to skip a point-release, that's really not a problem, I would think. I thought that was already the outcome of the discussion on the dev-list, as I understood it. regards, Martin On Jan 21, 2008 10:31 PM, Paul Spencer [EMAIL PROTECTED] wrote: Because artifacts where published, even if that was not the intent, the version number should be consider used. Paul Spencer Matthias Wessendorf wrote: On Jan 21, 2008 1:08 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: If something was publicly released as 1.2.1 already, then -- even if it was pulled -- please do not release 1.2.1 again. it wasn't released. Just the impl jars made it to public repo. which is (from the effect) close to a release ;-) -M Skipping a version number might cause some questions on the list. However, reusing a version number will result in the end user not knowing if they have the good version or the bad version, nor will anyone who tries to help them debug issues. On Jan 21, 2008 4:00 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: So we agree on 1.2.2? -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
