#50: Plone Mail Templates
- Contents
- Proposed by
- geoff
- Proposal type
- State
- rejected
Motivation
Using ZPT for email sucks. It's easy to screw up, easy to for spammers to munge, and a pain for end users (who are not developers) to customize.
Proposal
- Create a ZPT-like object specifically designed for creating mail.
- Build in capabilities to let both developers and end users customize things easily
Implementation
There are 3 use cases.
- Developer - A developer writes a mail template in the same way s/he would write a ZPT. Typically s/he creates a file on the file system. The file will show up in a skins directory somewhere. A developer can customize a mail template through the ZMI the same way s/he would a ZPT.
- Site administrator - A site administrator can customize the text of a mail template through a Plone interface. We indicate a set of variables at the top of the PMT file that the site administrator will be able to embed in his/her text via a simple macro system. Attributes in the PMT will control which sections the site admin can customize. Typically a site admin will be able to modify only the subject and body of the mail via a nice interface that shows all the available macros with basic documentation about what they are. One might want to embed code in the body of an email, in which case one might not want a site admin to customize it. We will be able to specify that some parts of the body of the mail will not be editable.
Implementation is by subclassing ZPTs and modifying their xml a bit. There will be a few extra steps in the parsing of the files.
- Parse the XML. Grab any named variables.
- Replace named variables in curly braces with
<span tal:replace="foo" i18n:label="appropriate_label" /> - Parse the ZPT and hold on to the parsed document.
To render, we take these steps
- Render the ZPT into XML.
- Parse the XML
- Transform the parsed XML into something that the mailer likes
I envision the format looking something like this:
<email>
<!-- Placeholders for variables available to end users when customizing
mail text. Values for these variables -->
<variables>
<variable name="first name" i18nlabel="my_email_first_name">
<description>The recipient's first name</description>
</variable>
<variable name="last name" i18nlabel="my_email_last_name"/>
<variable name="user name">
<description>The recipient's user name</description>
<value:tal content="optional/tales/expression/for/generating/value" />
</variable>
</variables>
<headers>
<to tal:content="some/tales/expression" />
<cc>somebody@example.com</cc>
<subject>Sample email</subject>
<header name="favorite-ice-cream">chocolate</header>
</headers>
<body>
<text wrap="0" i18nlabel="some label">This is a block of pre-formatted text. This text will be
unaltered by the parser.</text>
<text>This is a block of pre-formatted text. This text will be
unaltered by the parser except for wrapping, which will be done at the default of 68
characters. The reason for wrapping is that people might insert <span tal:replace="content/via/TALES" />.
People can also use the more non-developer-friendly macros as follows: Hello {first name} {last name}.
The stuff in the curly braces will be replaced.</text>
<text edit="text" size="30" maxlength="80">This is a block of pre-formatted text. When
an end-user customizes the text, s/he will be presented with an single line text input field 30 characters
long with max length 80.</text>
<text edit="textarea" rows="3" cols="60">This is a block of pre-formatted text. When
an end-user customizes the text, s/he will be presented with a textarea block 3 rows long and 60
columns wide.</text>
<text wrap="20">The end. This is a block of pre-formatted text. It will be wrapped at 20 characters.</text>
</body>
</email>