Re: [email] was RE: Validator inside of Email.java (RE: [email] Dumbster failing)

2004-10-26 Thread Stephen Colebourne
- Original Message -
From: Eric Pugh [EMAIL PROTECTED]
 So, on the second side..  I guess, to what extent do we validate email
 information?  I agree that requiring commons-validator seems a bit much
for
 a small project like [email] just to use it.  On the other hand, it does
 wrap the functionatliy up.

I am -1 to adding a dependency like commons-validator to [email]. If
necessary, we should copy the method adding comments to both implementations
about the duplicated code.

Stephen



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [email] was RE: Validator inside of Email.java (RE: [email] Dumbster failing)

2004-10-26 Thread Corey Scott
I believe the code for email validation is not too much (certainly
less than the whole of validator package).  Are you thinking of
duplicating it in place of the validation reference or removing the
validation from the functions and providing a validation function?

Either of which should not be too much work.  I believe the email
validation is based on some very clever javascript, this we can easily
convert?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [email] was RE: Validator inside of Email.java (RE: [email] Dumbster failing)

2004-10-26 Thread Matthias Wessendorf
see intermixed


 HumI'll answer the easy question first..  I think the 
 @author tags
 should stay since it is an option.  The PMC justs asks that 
 projects make a decision on it one way or the other.  So, for 
 [email], I'll register myself on the yes they should stay side.

yes ok :) no problem with it. In MyFaces, which is now in Incubator,
we keep them too. But Struts for instance has removed them.

 The reason is that it helps figure out who had impact on what 
 code, and at least for me, gives me the warm fuzzy's!  It 
 doensn't change copyright or anything, that remains with ASF. 
  I belive it encourages contribution to see your name in 
 lights and I would like them to stay.

yes! that's it ;-)

 So, on the second side..  I guess, to what extent do we 
 validate email information?  I agree that requiring 
 commons-validator seems a bit much for a small project like 
 [email] just to use it.  On the other hand, it does wrap the 
 functionatliy up.
 
 Can you think of way to have our cake and eat it too?  In 
 other words, what is involved in maybe adding some sort of 
 email validator decorate/helper class?  Maybe something in a 
 contrib directory showing how to do it..

well helperclazzes sounds more reasonable to me,
but does this blow up [email] ?

 [email] should remain small, and having a dependency on 
 commons-validator is a lot...

yes!
my +1 on remoing this dependency

 Eric
 
 PS, please tag your emails with [email], many folks filter on 
 that type of tag in commons!

sorry just forgotten...


Matthias

  -Original Message-
  From: Matthias Wessendorf [mailto:[EMAIL PROTECTED]
  Sent: Tuesday, October 26, 2004 9:25 AM
  To: 'Jakarta Commons Developers List'
  Subject: RE: Validator inside of Email.java (RE: [email] Dumbster
  failing)
 
 
  Want to say:
 
  A object represented by a clazz (subclass)
  of Email should be a valid Email.
 
  The validation should be done *before*
  creating an object of that class.
 
 
  -Matthias
 
   -Original Message-
   From: Matthias Wessendorf [mailto:[EMAIL PROTECTED]
   Sent: Tuesday, October 26, 2004 9:09 AM
   To: 'Jakarta Commons Developers List'; [EMAIL PROTECTED]
   Subject: Validator inside of Email.java (RE: [email] Dumbster 
   failing)
  
  
   Hi Eric,
  
   I just update my email sources.
   and looked abit on the patches
   you are submitting. Cool to have
   some unittest.
  
   Btw. I saw that EmailValidator
   of Commons Validator is used
   inside of Email.java;
   Does it realy make sence to
   validate an e-mail inside that class?
  
   shouldn't this work be done outside?
  
   eg. enter e-mail via Struts
   (validate it)
   in action.clazz passing the String
   to the class that is using [email] ?
  
   Just my thought.
  
   Btw. what should we do with the
   @author tags? since some projects
   of Apache/Jakarta are removing them.
  
   Regards,
   Matthias
  
-Original Message-
From: Eric Pugh [mailto:[EMAIL PROTECTED]
Sent: Monday, October 25, 2004 11:35 PM
Cc: Jakarta Commons Developers List
Subject: RE: [email] Dumbster failing
   
   
Not a problem.  I appreciate your working with me on this. I am 
looking forward to getting [email] whipped into shape!
   
ERi
   
 -Original Message-
 From: Corey Scott [mailto:[EMAIL PROTECTED]
 Sent: Monday, October 25, 2004 7:21 PM
 To: [EMAIL PROTECTED]
 Cc: Jakarta Commons Developers List
 Subject: Re: [email] Dumbster failing


 Ok, I have the tests all up and running with Maven.

 I have also made some minor mods, based on the tests or
improving the
 input checking (this is why some of the tests are failing,
there where
 against my changes not the HEAD version sorry)

 So once we get this formatting issue sorted, I will submit
to you the
 new patch.  This should raise the test coverage to 
 90+% for all
 (non-deprecated) classes.

 Thanks,
 Corey
   
   
   
   
 
   -
To unsubscribe, e-mail: 
 [EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]
   
  
  
   
 
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: 
 [EMAIL PROTECTED]
  
 
 
  
 -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]