Re: UIXEditableValue compareValues change
Hey Gab, this is fine. Comes along with JSF 2 as well Sent from my iPod. On 23.05.2009, at 01:48, Gabrielle Crawford gabrielle.crawf...@oracle.com wrote: Hi, I was planning on making a change to UIXEditableValue.compareValues. The details are here: https://issues.apache.org/jira/browse/TRINIDAD-1489 I don't think this is an issue, but since this is some really core code that's run for form controls I thought I'd see if anyone has objections. Thanks, Gabrielle
Re: [VOTE] SVN structure change (was: Re: [MyFaces CORE] SVN layout (was: Re: [source control] git and the ASF ...))
Ah. Good point! Sent from my iPod. On 22.05.2009, at 21:10, Bernd Bohmann bernd.bohm...@atanion.com wrote: Hello, +1 I would prefer /trunk - 2.0 /branches/myfaces-1.1.x /branches/myfaces-1.2.x because we are not using cvs anymore and the path already contains http://svn.apache.org/repos/asf/myfaces/core/ maybe we can omit the 'myfaces' in the branch name. Regards Bernd On Fri, May 22, 2009 at 5:27 PM, Matthias Wessendorf mat...@apache.org wrote: actually, I agree with Bernd. For the following layout: /trunk - 2.0 /branches/myfaces_1_1_x /branches/myfaces_1_2_x Two reasons for way making 2.0 trunk: -most current development is on-going in 2.0 (new spec) -most commits are going to the 2.0 branch (so, let's make it trunk) So, I am +1 on the above svn layout -Matthias On Sat, May 16, 2009 at 1:04 PM, Matthias Wessendorf mat...@apache.org wrote: from Bernd, on a different thread: Hello, I would suggest following layout 1.1.x branch/1.1.x 1.2.x branch/1.2.x 2.0.x trunk because the 2.0.x version is in development the other branches are only in bugfix state. On Fri, May 15, 2009 at 1:13 PM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: Hi, ... Ok, I filed this: https://issues.apache.org/jira/browse/INFRA-2053 maybe we should also think about making the JSF 1.1.x stuff a branch ... (since we already work on 2.0.x) what do people think if the 1.2 stuff becomes trunk And the following efforts are on a branch: -2.0.x -1.1.x +1 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: UIXEditableValue compareValues change
actually jsf 2.x ... On Sat, May 23, 2009 at 10:02 AM, Matthias Wessendorf mwessend...@gmail.com wrote: Hey Gab, this is fine. Comes along with JSF 2 as well Sent from my iPod. On 23.05.2009, at 01:48, Gabrielle Crawford gabrielle.crawf...@oracle.com wrote: Hi, I was planning on making a change to UIXEditableValue.compareValues. The details are here: https://issues.apache.org/jira/browse/TRINIDAD-1489 I don't think this is an issue, but since this is some really core code that's run for form controls I thought I'd see if anyone has objections. Thanks, Gabrielle -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (TRINIDAD-1489) get a valueChangeEvent for bigDecimal even though user didn't make a change.
[ https://issues.apache.org/jira/browse/TRINIDAD-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712408#action_12712408 ] Matthias Weßendorf commented on TRINIDAD-1489: -- yeah, this comes with JSF 2.x (I think 2.1) as well: http://wiki.java.net/bin/view/Projects/Jsf2MR1ChangeLog (see C007) get a valueChangeEvent for bigDecimal even though user didn't make a change. Key: TRINIDAD-1489 URL: https://issues.apache.org/jira/browse/TRINIDAD-1489 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gabrielle Crawford When attribute data type is BigDecimal and af:convertNumber is used Trin treats the attribute as if the attribute value is changed even though the attribute value has not been changed. Under the covers the numberConverter is using the java decimalFormat class, and things can get a little funny when you use bigdecimal, because bigdecimal remembers formatting information like scale. So 2.0 is not equal to 2.00 in bigdecimal. We can add logic to UIXEditableValueHolder that if .equals fails and if the values are the same type and implement comparable we should then check compareTo. There are 2 workarounds for now. 1] apply the pattern to the bigdecimal in the getter, so in the salary example code above return newSal instead of sal. 2] check compareTo in the setter, and don't set if you get 0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Tomahawk
Guys, I'm interested on the Tomahawk project. Am I in the correct list? RPM
Re: Tomahawk
Hi Ramiro, Yes, you're fine here. Best regards, Ganesh Ramiro Pereira de Magalhaes schrieb: Guys, I'm interested on the Tomahawk project. Am I in the correct list? RPM
[jira] Commented: (TOMAHAWK-1423) title:validateRegExpr with a4j:support does not display Summary message
[
https://issues.apache.org/jira/browse/TOMAHAWK-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712437#action_12712437
]
Christian Kaltepoth commented on TOMAHAWK-1423:
---
Which way do you use to declare you message bundle and which JSF version are
you using?
If you are on JSF 1.1 you must use a4j:loadBundle instead of f:loadBundle
to reference bundle messages during ajax re-rendering.
See:
http://www.jboss.org/file-access/default/members/jbossrichfaces/freezone/docs/devguide/en/html/a4j_loadBundle.html
title:validateRegExpr with a4j:support does not display Summary message
---
Key: TOMAHAWK-1423
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1423
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Validators
Affects Versions: 1.1.8
Reporter: Boryana Chavkova
When I am using validateRegExpr from version 1.1.8 and a4j tag library,
custom summary message and detail message don't display.
I debuged ValidationBase.class and found that getStringValue(FacesContext
context, ValueExpression vb) returns null when invoke onblur, but when
submit the form this returns correct value.
This is the code:
t:panelGroup id=fullNamePanel
t:inputText id=fullName forceId=true
value=#{mAdultSignUpBean.adult.bcard.fullName} required=true
t:validateRegExpr pattern=[a-zA-Z-\. ]{1,120}
summaryMessage=#{error['format.fullname']} /
a4j:support event=onblur reRender=fullNamePanel
ajaxSingle=true/
/t:inputText
t:message for=fullName styleClass=errormsg showDetail=true /
/t:panelGroup
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
