Devleoping a Product to Create and E-mail Newsletters

Tue Sep 11 14:29:02 UTC 2007

My initial thought, not claiming to be an expert, would be to consider
refactoring the PloneGazette project.

On 9/11/07, George Lee <georgeleejr at gmail.com> wrote:
>
>
> 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.
>
>
> _______________________________________________
> Product-Developers mailing list
> Product-Developers at lists.plone.org
> http://lists.plone.org/mailman/listinfo/product-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-product-developers/attachments/20070911/6719e6cc/attachment-0002.html>