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:
> >
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
> versi
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.
R
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:
>
> http://svn.apache.org/repo
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 thi
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 on
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]>:
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 v
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]> w
+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
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
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 depreca
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-valid
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 th
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
myfaces-co
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
> co
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 vers
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)
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
s:va
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
s:validateUrl
20 matches
Mail list logo