Hi,
i think we should not use the version to distinguish between the 1.2
and 1.1 branch of commons (in the release artifacts name),
because the 1.2 (trunk) is not a improved 1.1 version.
afaik there could be circumstances where maven prefers the higher
version even in a jsf 1.1 application.
Volker Weber schrieb:
Hi,
i think we should not use the version to distinguish between the 1.2
and 1.1 branch of commons (in the release artifacts name),
because the 1.2 (trunk) is not a improved 1.1 version.
afaik there could be circumstances where maven prefers the higher
version even
Hi
I have committed on trunk the changes wanted on myfaces-commons. The layout
is this:
myfaces-commons-utils
myfaces-commons-converters
myfaces-commons-validators
myfaces-commons-example
On Wed, Jun 18, 2008 at 2:21 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Volker Weber schrieb:
Hi,
Hi,
validateEqual should be deprecated because validateCompareTo it is better
(according to the suggestion of Mike), so this validator should stay on
tomahawk. The rest of converters and validators only be referenced by
if validateEqual works in non tomahawk environment why make it
Leo,
I will start adding the base exporterListener to commons after your
refactoring.
Thanks.
On Tue, Jun 17, 2008 at 1:56 AM, Leonardo Uribe [EMAIL PROTECTED] wrote:
Hi
I'll start to refactor myfaces-commons to the new proposed layout (I'm not
started this yet because it was necessary check
+1 for adding examples.
On Tue, Jun 17, 2008 at 1:12 PM, Hazem Saleh [EMAIL PROTECTED] wrote:
Leo,
I will start adding the base exporterListener to commons after your
refactoring.
Thanks.
On Tue, Jun 17, 2008 at 1:56 AM, Leonardo Uribe [EMAIL PROTECTED] wrote:
Hi
I'll start to
BTW, I believe a vote was already taken on commons, and the result was
that commons would be JSF 1.2 only with a 1.1 branch if ppl. wanted to
create one.
With this in mind, I am strongly -1 for the 1.2 code using 1.1 artifacts.
On Mon, Jun 16, 2008 at 5:24 PM, Leonardo Uribe [EMAIL PROTECTED]
It should be deprecated because it adds nothing over validateCompareTo
and does not do the job of locating/computing/comparing two equal
input component values as well as validateCompareTo does.
Or to look at it another way, defining a validateEquals jsp or facelet
tag handler that points to the
Hi,
i had missread the previous posts :-(
I validateCompareTo goes into commons (i was under the impression that
not, because tomahawk specific code)
than it's perfectly ok to skip (and deprecate in tomahwak) validateEquals.
Regards,
Volker
2008/6/17 Mike Kienenberger [EMAIL PROTECTED]:
Please see here:
http://www.nabble.com/-VOTE--Commons-API-JSF-1.2-only-tp14178115p14180119.html
The consensus was to have commons be JSF 1.2 and a separate branch for
JSF 1.1 if desired. Therefore, we should place the 1.1 code in a
separate location and the main trunk folders should be JSF 1.2
Ahhh, Ok, thanks for the information. That's right. If exists a vote, no
way.
Checking the svn there is a jsf 1.1 branch here:
http://svn.apache.org/repos/asf/myfaces/commons/branches/jsf_11/
And the trunk is the jsf 1.2 branch:
http://svn.apache.org/repos/asf/myfaces/commons/trunk/
But if
And by the way, better remember that there will soon be a JSF2.0
branch..
On Tue, 2008-06-17 at 12:57 -0500, Leonardo Uribe wrote:
Ahhh, Ok, thanks for the information. That's right. If exists a vote,
no way.
Checking the svn there is a jsf 1.1 branch here:
Hi
I'll start to refactor myfaces-commons to the new proposed layout (I'm not
started this yet because it was necessary check the actual state of
converters and validators and solve some related issues):
myfaces-commons-converters
myfaces-commons-converters12
myfaces-commons-validators
How about moving the JSF version to a folder?
commons-utils/
commons-11/myfaces-commons-converters
commons-11/myfaces-commons-validators
commons-12/myfaces-commons-converters
commons-12/myfaces-commons-validators
Just makes for a cleaner structure IMO and makes it look less like 1.2
support is
On Mon, Jun 16, 2008 at 6:16 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
How about moving the JSF version to a folder?
commons-utils/
commons-11/myfaces-commons-converters
commons-11/myfaces-commons-validators
commons-12/myfaces-commons-converters
commons-12/myfaces-commons-validators
On Fri, Jun 6, 2008 at 1:06 PM, Mike Kienenberger [EMAIL PROTECTED] wrote:
I'd recommend not migrating t:validateEqual across to myfaces-commons.
t:validateEquals is a special case of t:validateCompareTo, and, if I
recall correctly, the code in validateEquals is not as flexible as the
code in
Hi
I'll start to upgrade component from sandbox to tomahawk.
The first item on my list of todos is move this converters and validators
(first check and solve possible issues on JIRA)
s:convertBoolean
s:convertDateTime
s:convertNumber
s:validateCompareTo
s:validateCSV
s:validateISBN
Leonardo Uribe wrote:
Hi
I'll start to upgrade component from sandbox to tomahawk.
The first item on my list of todos is move this converters and validators
(first check and solve possible issues on JIRA)
s:convertBoolean
s:convertDateTime
s:convertNumber
s:validateCompareTo
s:validateCSV
On Fri, Jun 6, 2008 at 8:54 AM, Paul Spencer [EMAIL PROTECTED] wrote:
Leonardo Uribe wrote:
Hi
I'll start to upgrade component from sandbox to tomahawk.
The first item on my list of todos is move this converters and validators
(first check and solve possible issues on JIRA)
I'd recommend not migrating t:validateEqual across to myfaces-commons.
t:validateEquals is a special case of t:validateCompareTo, and, if I
recall correctly, the code in validateEquals is not as flexible as the
code in validateCompareTo. There's no point in maintaining the
inferior limited
20 matches
Mail list logo
