[seam-dev] Seam 3 Mail Feedback Follow-up

[Cody Lerum]

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 at 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 at 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 at 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/6f70057cca7da712576c21f44bda80082ae1f0a1/examples/sendmail/src/main/java/org/jboss/seam/mail/example/Person.java
>>
>> 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 at nothingtosee.org",
>> "dan at test.com") is something we could do, but we would have to ditch
>> the to("Dan", "dan at test.com"). People would have to create personal +
>> address recipients via something like to(new BaseEmailContact("Dan".
>> "dan at 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 at test.com")
>>   to("cody at 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 at test.com", "Cody")
>>
>> and require
>>
>>  to(new BaseEmailContact("cody at test.com", "Cody")
>>
>> this would allow a var args address only to/from/cc/bcc/replyTo
>>
>> Thus you could do:
>>
>> to("cody at test.com")
>> to("cody at test.com", "dan at test.com")
>>
>> but anything with the acutal name would need to be done with
>>
>> to(new BaseEmailContact("cody at 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 at test.com", RoleType.ADMIN);
>>
>> to(user);
>>
>> Thoughts?
>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.com
> http://scrumshark.com
> "Keep it Simple"
>