5:22 p.m.
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?
8:51 p.m.
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"
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"
4:27 p.m.
On Sun, Feb 27, 2011 at 22:06, Cody Lerum <cody.lerum(a)gmail.com> wrote:
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.
+1
I can't think of a case when someone said "dang it, I made too many
interfaces". In fact, I usually want to club someone over the head for
forcing me to replace a whole subsystem because the author failed to make
use of an interface.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
4:23 p.m.
On Sun, Feb 27, 2011 at 18:22, 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());
Excellent.
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...
Good thinking! I like it.
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")
What about assuming that if there are exactly two arguments, and the second
argument is not an e-mail address, then you assume it's the name part for
the preceding. I know that's there's a hint of guesswork in there, but it
nicely caters to the prototype use case and likely will be appreciate to
"just work".
Example:
to("john.smith(a)acme.com", "joe.cool(a)peanuts.org",
"john.doe(a)example.org") ->
3 recipients
to("john.smith(a)acme.com", "joe.cool(a)peanuts.org") -> 2 recipients
to("john.smith(a)acme.com", "John Smith") -> 1 recipients
You can use a regular expression to check for an e-mail address in the
second argument position, so long as you make it a configurable setting.
Keep in mind you can already do (if I'm not mistaken):
to("John Smith <john.smith(a)acme.com>", "Joe Cool
<joe.cool(a)peanuts.org>")
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);
But you are right, there are plenty of other options. I think it's safe to
treat the two argument invocation as a special case.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
5615
days inactive
5616
days old
4 comments
3 participants
participants (3)
-
Cody Lerum -
Dan Allen -
Lincoln Baxter, III