Devleoping a Product to Create and E-mail Newsletters

George Lee georgeleejr at gmail.com
Tue Sep 11 06:20:01 UTC 2007


Hi,

With the fall comes my chance to do a little more programming than the
spring or summer. =)  And I'm excited because now I can ask questions on
product-developers to get guidance on the overall idea and framework for a
product I'm working on -- the list wasn't around a year ago.

I doubt I'd be able to see this all the way through to the end to make a
really polished product a lot of others will use, but I think I can make a
pretty good version that if other people want, they can take to another
level. But to make it more likely the code is useful, I want to talk with
folks about it first!

I'm working on a product to create and e-mail newsletters, including
newsletters that compile summaries of different content objects ("Upcoming
Events," "New Job Postings," etc.). I created an old version for Plone 2.5
last year using Zope 3 views here and there to give some more power and
flexibility to the the newsletters, but it was fairly rough.

I'm taking some inspiration from Constant Contact - when I tried editing an
e-mail through their interface, it was pretty useable. Basically you choose
a pre-defined template, which consists of a few different parent blocks;
within each parent block, you can add different subblocks of predefined
types ("Greeting," "Article," "Coupon," etc.); then you can edit the
settings of a subblock - style, color, main iamge, add regular text, add
rich text and images and links, etc.

I worked on a rough prototype of this and then afterward thought - hey, this
reminds me of viewlets. But viewlets were too rigid because of all the
wiring required just to associate viewlet managers with viewlets, on a
site-wide basis rather than per newsletter. Then I thought, this reminds me
of portlets! And that's where I'm having a lot of fun, using plone.portlets
to set this up. I have a partial version of the product done that can
display newsletters and allow some editing using the plone.portlets edit
views, so in terms of using plone.portlets a good chunk of that work is
done.

Here's my plan, and some questions. Here's how I imagine a user adding a
newsletter.
 * Initially, for simplicity and also to centralize newsletters since too
many shouldn't be going out all the time to a bunch of the same people,
newsletters are added in a central place. The current plan -- in the same
way as content rules, have a centralized storage utility at the Plone Site
root, accessible via plonesite/@@manage-newsletters
  * When a newsletter is created, a user decides what template to use for
it. The newsletter than automatically creates an appropriate number of
"newsletter area" objects, stored in a PersistentMapping. Each newsletter
area object corresponds to one of the main parent blocks of a newsletter.
The user assigns portlets to the newsletter areas - with a set created by
default. The types of portlets available to a newsletter area are pre-wired.
  * The portlets are stored with the help of a portlet manager designed
specifically to keep track of newsletter areas. It took me a while to
understand this, but a portlet manager is not "an object that stores
portlets" - but rather, "an object that can say how to store portlets
associated with different objects." So plone.dashboard1, plone.dashboard2,
plone.dashboard3, and plone.dashboard4 are associated with site-wide portlet
managers that manage how portlets are assigned to the first, second, third,
and fourth dashboard columns for different users.
   * With different portlet manager renderers, we can make the newsletters
and portlets appear in different contexts - to view them and edit them; in a
web version, HTML e-mail version, and text e-mail version. This can take
advantage of some of the existing views.
   * Right now, none of this is done with Archetypes, but a lot of Zope
objects ... an example URL right now is
http://plonesite/++newsletter++events1/++area++header/@@manage-newsletter-portlets

Some example portlets - some inspired by Constant Contact
  * Title portlet, whose data would include (1) a logo, and (2) title text
  * Greeting portlet, where a user could choose from a few different ways of
greeting people (by first name, more formally, or generically)
  * A "summary listing" portlet, which would pull up different summaries of
items based on search criteria (a Smart Folder light; like the Events
portlet or News portlet)
  * Article portlet, with a main photo and then article text
  * Donate Now portlet, whose data would include PayPal information
  * Opt-out portlet, whose data would include a little happytalk and a link
to opt out of future newsletters

In terms of how newsletters are sent and stored, ideally:
  * There would be a way to send test newsletters
  * They could look up e-mails in a variety of ways -- from the portal's
member data, from user info stored on the newsletter or the newsletter
storage utility -- and send out individualized or mass e-mails
  * They could be archived up on sending by storing a static HTML version
  * A cronjob on the system could be set up to send newsletters out on a
regular basis

So here are some questions:
  * What are folks' thoughts on this in general?
  * I have seen in a couple of e-mails before that people think e-mail list
management is a task best left outside of Plone and for Plone to hook into;
any thoughts on this?
  * Does this seem like an appropriate use of plone.portlets? (I think it's
pretty exciting -- I can also see a similar technique being used to set up
some flexible templates on a Plone site itself that people could fill in.)
Are there techniques existing products like CompositePack are using that
this is duplicating or could learn from?
  * Does the idea of centralizing newsletter storage make sense?
  * Is it possible to index newsletters in the same way as Archetypes
content, or to wrap newsletters into Archetypes-ish objects down the line?

Some specific coding questions:
  * The GenericSetup handler for portlets.xml automatically chooses to
create a PortalManager instead of allowing an alternative portal manager
(e.g., for one that would have a different method for retrieving the addable
portlets); it would be great if there was an optional flag for this.
  * Also while relying on calls to plone.portlets and plone.app.portlets
code, there are issues where after editing, URL's redirect to things like
http://plonesite/newsletterevents1/areaheader/... instead of
http://plonesite/++newsletter++events1/++area++header/... I'm still looking
into how to address this
  * How does one distinguish what to put into different packages such as
plone.portlets and plone.app.portlets? Right now I have three packages
communitytechnology.newsletter, communitytechnology.app.newsletter, and
ywasite.newsletterdefinitions (the third being a specific implementation
defining different portlets and newsletters), but I don't know if the first
two are really a right use of the "app" idea, or how to really distinguish
what would go in one or the other -- independence from Zope3? From Plone?


Thanks for any feedback and guidance!

Peace,
George
-- 
View this message in context: http://www.nabble.com/Devleoping-a-Product-to-Create-and-E-mail-Newsletters-tf4420534s20094.html#a12608760
Sent from the Product Developers mailing list archive at Nabble.com.





More information about the Product-Developers mailing list