Devleoping a Product to Create and E-mail Newsletters
petschki
peter.mathis at kombinat.at
Thu Sep 13 11:18:57 UTC 2007
hi,
we've been thinking about this topic a while ago and decided to refactor
PloneGazette to our needs. the result of this refactoring is an
archetypes based newslettertool generated with UML and AGX using nearly
the same features as PG (MaildropHost, ...)
we've added usefull subscriber informations (graduation, salutation,
first/lastname, organisation) and enabled personalization within the
newsletter template.
the newsletter can handle all standard portal_types (wrapped by a
newsletter_typeview_wrapper template which defines the "newsletterlook"
of each used type).
we've made a ATTopic wrapper so you can filter site content with ATTopic
criterions and include the results in your newsletter.
there's also a single ContentReference type where you can "symlink"
existing items into your newsletter. since the newsletter is folderish
you have of course all the folder_contents benefits from plone 2.5 like
sorting, deleting, copy/paste ....
this product is developed for plone 2.5
i will put the source to the collective repository soon but if anybody
is interested in our KNewsletter product right now please send me a mail.
peter
David Bain schrieb:
> 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
> <mailto: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/.
> <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
> <http://Nabble.com>.
>
>
> _______________________________________________
> Product-Developers mailing list
> Product-Developers at lists.plone.org
> <mailto:Product-Developers at lists.plone.org>
> http://lists.plone.org/mailman/listinfo/product-developers
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Product-Developers mailing list
> Product-Developers at lists.plone.org
> http://lists.plone.org/mailman/listinfo/product-developers
More information about the Product-Developers
mailing list