commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joel Trunick" <joel.trun...@webifysolutions.com>
Subject Re: [email] Using Templates for Mail Message
Date Fri, 09 Dec 2005 22:09:29 GMT

There certainly is a place for this type of library, whether or not in
belongs in commons-email. Velocity has VelocityStruts, and
VelocityViewServlet, what is being described is quite analogous.

It has been implemented multiple times in usually over-simplified ways,
and it would be great to standardize a more complete implementation. The
Jakarta libraries are powerful, and I was able to create a quite useful
emailing/templating/email-control package by leveraging the following
libraries:

commons-mail
commons-configuration
Velocity

It allows developers to specify email templates and for an admin/end
user to control addressing emailing options. I'd be willing to donate
this to open source. It's not a heck of a lot of code, but enough that
you don't want to rewrite. Let me know which project is most suited and
Ill look into submitting this, otherwise sourceforge/java.net would work
as well.

There are two config files (loaded by commons-configuration), along with
a sample template. See below for a idea of how they work. Let me know if
there is interest.

Joel

email.properties - for end user email control
email_templates.properties - for developer template specifications.
Hello.txt - Velocity template. 

# email.properties file
#
# Default from, reply to, and bounce-back addresses.
# email.set.from=automated_software@webifysolutions.com
# email.set.bounce=bounce_back@here.com
#
# Add email recipients (all emails).
# email.add.to=spam_me@com
# email.add.cc=spam_me2@com
# email.add.bcc=spam_me3@com
# 
# Turns on/off all emails
# email.send=true
#
# Addressing/Control of specific emails
# email.message.hello_world.add.to=spam_me@com
# email.message.hello_world.add.cc=spam_me@com
# email.message.hello_world.add.bcc=spam_me@com
# email.message.hello_world.send=false
#
# Turns on/off JNDI lookup
# email.use.jndi=true
#
# JNDI lookup name
# email.use.jndi.path=java:comp/env/mail/MailSetup
#
# Change hostname
# mail.smtp.host=localhost
# mail.smtp.port=25000
# mail.smtp.user=user
# mail.smtp.password=password
#
# ---- TESTING OPTIONS
# Sends emails to this address ONLY.
# email.set.address.to=spam_me@co.com
#
# Doesn't send any emails, but forwards to this address ONLY.
# Useful for testing whether email was addressed correctly.
# email.set.forward.to=spam_me@co.com
# ---- END TESTING

# email_templates.properties
#
# Template Emails (Velocity Macro emails)
#
# These files should refer to files on the classpath.
# email.message.hello_world.file.vm.text/html=on/classpath/hello.html
# email.message.hello_world.file.vm.text/plain=hello.txt

<!-- Example template file  -->
#set($email.Subject = "Your Hello World Email")
<html>
<body>
<p>Hello World</p>
</body>
</html>



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The problem I would see with having this in email, even as a utility, is
that it isn't e-mail specific.

While your use case deals with the file system and (presumably?) a
bean-type substitution (e.g., @@LOGIN@@, user.getLogin()), there is a
broader scope of retrieval of information from other sources (database,
property files, etc). The use cases (and dependencies to match) could
get well out of control for a simple project aimed at making e-mail
easier to use.

Perhaps a utility class for your use case could simply deal with
String's replace/replaceAll?

Brian


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message