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* <
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
[email protected]
<mailto:[email protected]>
http://lists.plone.org/mailman/listinfo/product-developers
------------------------------------------------------------------------
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
