9:06 p.m.
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.
-C
On Sun, Feb 27, 2011 at 7:51 PM, Lincoln Baxter, III
<lincolnbaxter(a)gmail.com> wrote:
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> 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("seam(a)test.test", "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("emmanuel(a)nothingtosee.org",
> "dan(a)test.com") is something we could do, but we would have to ditch
> the to("Dan", "dan(a)test.com"). 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("cody(a)test.com")
> to("cody(a)test.com", "Cody")
>
>
> Thats what I have for now. The one question I have is do we just drop
> the ability to do
>
> to("cody(a)test.com", "Cody")
>
> and require
>
> to(new BaseEmailContact("cody(a)test.com", "Cody")
>
> this would allow a var args address only to/from/cc/bcc/replyTo
>
> Thus you could do:
>
> to("cody(a)test.com")
> to("cody(a)test.com", "dan(a)test.com")
>
> but anything with the acutal name would need to be done with
>
> to(new BaseEmailContact("cody(a)test.com", "Cody")
>
> Of course if people are using existing objects it would be easier to
> just implement the EmailContact interface
>
> User user = new User("Cody", "cody(a)test.com", 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"