Hey Cody, Awesome Job! Very mucho awesome job. > > 3. From Lincoln on having the EmailAttachment as an interface. > >    I'm not really sure how useful this is going to be as you are > going to have to implement quite a few methods. I'm not stuck on this one. It's a simple enough class, but you can never be too safe, and it's difficult to go back :) Forge tells us that there are only 6 methods that need to be in the interface. *wink* [seam-mail-api-base] EmailAttachment.java $ ls [methods] public::getBytes()::byte[] public::getContentDisposition()::ContentDisposition public::getContentId()::String public::getFileName()::String public::getHeaders()::Collection<Header> public::getMimeType()::String It would be pretty straight-forward if you did want to break these out into their own interface and move the implentation (still in the api-base package) to BaseEmailAttachment. You could also add a reference to this default implementation in the JavaDocs. Again, just an idea. It really probably isn't a big deal since all you need to do is transform your data into the object you've already provided. I'd love to get Dan's expert opinion ;) One more thing. It looks like you are doing some UUID work in this class here?   public EmailAttachment(  String fileName,  String mimeType, ContentDisposition contentDisposition,  byte[] bytes){     this.contentId=UUID.randomUUID().toString();     this.fileName=fileName;     this.mimeType=mimeType;     this.contentDisposition=contentDisposition;     this.bytes=bytes;   } If you were to move Attachments to an interface, this might be something that needs to move to the EmailMessage impl itself. That might be another reason either for or against this, but something to consider :) Anyway. I'm done! Doesn't really matter either way I think. Cheers! And again, awesome job! --LB3 On Sun, Feb 27, 2011 at 6:22 PM, Cody Lerum <cody.lerum(a)gmail.com&gt; wrote: > > 1. From Lincoln > > Utilizing an Interface for handling the different ways one could > create an email template. - > https://issues.jboss.org/browse/SEAMMAIL-19 > >    This is Done. > > VelocityMailMessage vmm = velocityMailMessage.get(); > >      vmm.from(&quot;seam(a)test.test&quot;, "Seam Framework") >            .to(person) >            .subject("HTML Message from Seam Mail - " + > java.util.UUID.randomUUID().toString()) >            .bodyHtml(new VelocityClassPathTemplate("template.html.vm")) >            .put("version", "Seam 3") >            .importance(MessagePriority.HIGH) >            vmm.send(session.get()); > >   the contact fields also support a interface as well so one only > need implement a getName and getAddress method on their User entity > (for example) in order to pass it directly into an email - > > https://github.com/seam/mail/blob/6f70057cca7da712576c21f44bda80082ae1f0a... > > 2. From Emmanuel > >  a. the from and all contact fields already support a single argument > being the address >  b. the ability to have a var args  to(&quot;emmanuel(a)nothingtosee.org&quot;, > &quot;dan(a)test.com&quot;) is something we could do, but we would have to ditch > the to("Dan", &quot;dan(a)test.com&quot;). People would have to create personal + > address recipients via something like to(new BaseEmailContact("Dan". > "dan@test.com")...more on that further down >  c. all the contact methods (from/to/cc/bcc/replyto) all support > collections being passed into them. >  d. I've added an a no arg send() method >  e. Typesafe templating is going to have to come later and I'm going > to need to lean on someone for inspiration. > > 3. From Lincoln on having the EmailAttachment as an interface. > >    I'm not really sure how useful this is going to be as you are > going to have to implement quite a few methods. > > 4. From José Rodolfo Carrijo de Freitas reguarding no arg send() > >   This has been added. > > 5. From Dan via ALR reguarding ordering of the name and address in > contact methods > >   I've reordered everything to aways takes Address first and then Name if > any. > >   to(&quot;cody(a)test.com&quot;) >   to(&quot;cody(a)test.com&quot;, "Cody") > > > Thats what I have for now. The one question I have is do we just drop > the ability to do > >   to(&quot;cody(a)test.com&quot;, "Cody") > > and require > >  to(new BaseEmailContact(&quot;cody(a)test.com&quot;, "Cody") > > this would allow a var args address only to/from/cc/bcc/replyTo > > Thus you could do: > > to(&quot;cody(a)test.com&quot;) > to(&quot;cody(a)test.com&quot;, &quot;dan(a)test.com&quot;) > > but anything with the acutal name would need to be done with > > to(new BaseEmailContact(&quot;cody(a)test.com&quot;, "Cody") > > Of course if people are using existing objects it would be easier to > just implement the EmailContact interface > > User user = new User("Cody", &quot;cody(a)test.com&quot;, RoleType.ADMIN); > > to(user); > > Thoughts? > > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"

Now that I think about it, implementing it as an interface would cut the method count down on the MailMessage/VelocityMailMessage interfaces quite a bit...and from a maintenance perspective I'm worried about those getting too large since many of the methods have to be replicated on MailMessage + VelocityMailMessage and any future Templating systems we support. Or we just drop the builder pattern all together. I skeptical of someone implementing the EmailAttachment interface on their own, but it can't hurt and will make the api cleaner.