Posted about 1 year ago by Christopher Johnson
The Sites Using GetPaid page had become a nightmare to maintain with kupu and I simply couldn't edit it without things blowing up. So, I am really excited to announce that the page is now something organized, lovely, and scalable :D.
I went
... [More]
for my inclination to use structured data and some nice features to clean that mess up and used the ATSuccessStory product (what is also used for sponsors on the site...this is a version slightly customized by the product author, frapell).
Soo.....check out the all new, improved and attractive http://plonegetpaid.com/why/sites-using-getpaid/
I added 4 new sites that hadn't been there previously:
ABB Orderliterature.com > read moreNatural Awakenings Magazine > read moreHealth Food Guide > read moreWomen of Reform Judaism > read more
You will also notice that there is a portlet with rotating site features on plonegetpaid.com to highlight the sites as you navigate around.
We have some really great example sites out there, so please have a look!
If you have a site to add - please let me know - I am now all caught up with all the sites I know of. Also, if you want to send changes to any info there, please let me know. [Less]
Posted about 1 year ago by Christopher Johnson
The CIA bot dumped a long list of checkin updates into #getpaid yesterday afternoon, and remarkably we passed our 2000th revision! In that swirl of code, paypal workings got fixed thanks to duffyd, some error controls and bug fixes to the
... [More]
getpaid.report component were added (and perrito666 hit the 2000 milestone!), googlecheckout got updated by dunny, and more. See changelog.
Thanks to all who have been working on the project!
Other noteables from GetPaid:
GetPaid 0.6.1 tarball now has 895 downloads and has surpassed the 0.3 downloads total!
Please don't forget - we are part of Plone Conference sprint! If you want to partake, please sign up here. [Less]
Posted about 1 year ago by Christopher Johnson
The CIA bot dumped a long list of checkin updates into #getpaid
yesterday afternoon, and remarkably we passed our 2000th revision! In
that swirl of code, paypal workings got fixed thanks to duffyd, some
error controls and bug fixes to the
... [More]
getpaid.report component were added
(and perrito666 hit the 2000 milestone!), googlecheckout got updated by
dunny, and more. See changelog.
Thanks to all who have been working on the project!
Other noteables from GetPaid:
GetPaid 0.6.1 tarball now has 895 downloads and has surpassed the 0.3 downloads total!
Please don't forget - we are part of Plone Conference sprint! If you want to partake, please sign up here. [Less]
Posted about 1 year ago by Christopher Johnson
Recap
Last week we learned:
(12:04:11 AM) dixond: effectively what I've built is a way to turn a Plone site with GetPaid into an advertising channel, where people can pay to publish their content for a fixed time. The basic framework and
... [More]
concept can be extended then to other things also.
Stepping down from dixond's elloquent marketing-speak, the use case is something like this: A user needs some credit to make their content public in some way (ie "for a week" or by virtue of a group membership).
OK, the nuts and bolts:
1) ICreditRegistry for storing the credits (can obviously be in RDBMS but my trivial implementation uses ZODB and BTrees)
2) TickingMachine subscriber that knows about ICreditPublishedContent and applies some rules around send reminder emails, depublish, etc
3) Archetypes schema extender profile for ICreditPublishedContent to track stuff like 'weeks remaining published'
4) Various portlets to allow purchasing credit and using that credit to publish ICreditPublishedContent
5) A few basic content types to represent the credit being purchased
Basically, what I've been building is a way to buy 'non-things' much like the notion of the 'donatable' type and to keep track of them and then use them for controlling access to arbitrary actions later. At present it works great, I'm spending most of my time 'generic-ifying' it so that it can be re-used elsewhere and isn't tied too closely to my specific use-case. Also on the list are other credit types like 'group membership' etc. Once I've generic-ified it enough this should be 'easy'.
Currently, three packages: getpaid.creditpublish, getpaid.creditregistry, getpaid.purchasablecredit
Future extensions could also allow content to be accessed by using credits, if a payment processor is implemented which consumes credits.
What are others saying: "that's a really needed usecase of getpaid - lots of people will be hopping happy :)" -duffyd on #getpaid
New stuff
So, it did land in the repo - in sandbox: https://getpaid.googlecode.com/svn/sandbox/dixond/
Here is the full post dixond made (can be found in mailing list archive also):
I have been busy implementing a slightly different sort of use-case on
top of GetPaid for the last couple of weeks. The scenario is based
around a site where the site owner would like to charge the general
public to run, eg, user-submitted advertisements for a fixed period of
time. Think 'classified ads' or similar. The user is put in complete
control of publishing their content according to a policy (eg, the
first one implemented is for week-by-week publishing). The user pays
for a 'week' of credit, and can then consume those in publishing their
own content for that period of time. Also on the cards is
month-by-month group membership, which could then give them access to
special roles etc for 'all you can eat publishing'.
The overall framework is a relatively big, semi-independent
component/app in its own right, but the payment portion of it is tied
quite closely to GetPaid, and the rest seems to me to tie in nicely to
GetPaid as a whole, so I've attached it in name and spirit to GetPaid
for the moment ;)
There are three pieces that I have uploaded code for currently, all
of them relatively divorced from the nitty-gritty implementation
details and specifics of the use-case that birthed them:
getpaid.purchasablecredits
-- This is just a very simple content type with Title, Description, and
Price that acts as a sort of 'meta-product'. Its only purpose is to be
a buyable type that you can put any details in that you want.getpaid.creditregistry -- This is a very basic registry tool to
store 'credits'. The interface could very easily be implemented with
collective.lead in an RDBMS, but the package contains a simple
implementation of getpaid.creditregistry.interfaces.ICreditRegistry
which uses a Persistent utility in the ZODB and BTrees to store the
purchased credits and allow them to be added/removed.
getpaid.creditpublish -- This is where all the action is. A
number of different pieces all collaborate inside here to make
everything hang together:
Event handler that watches for
purchases of content items providing IOneWeekPublishedCredit and
increments the counters in the ICreditRegistry utility appropriatelyPortlet providing the mechanism for purchasing 'One Week
Publishing' credits. It gets the price and description of this from any
content item that implements IBuyableContent - when the portlet is
created it asks for the UID of an item to use for
Title/Description/Price - the 'representative object'Adapter from the IOrder, ILineItem, and 'representative object' to
be able to add credit records into the ICreditRegistry utility
Portlet to allow users to publish/depublish IOneWeekCreditPublishedContent content items (marked with ZCML).schema
extender for items marked with IOneWeekCreditPublishedContent to
provide some utility fields (weeksLeftPublished,
republishedReminderSent)Event handler subscribed to Products.TickingMachine.ITickEvent.ITickEvent:
this handler provides the de-publish/re-publish logic that drives the
time-based publishing. It runs however often you have your ticking
machine set, and runs a catalog search for
IOneWeekCreditPublishedContent items that have expired or are about to
expire and performs various policy logics on them (eg, re-publish for
another week if the user has requested that, de-publish if they are out
of credit, etc)
The various portlets and subscribers are geared currently
to the IOneWeekCreditPublishedContent policy, but there is no reason
other policies can not be added and patterned off the existing one. In
fact I intend to do this for group membership.
Several dependencies are introduced by getpaid.creditpublish:
archetypes.schemaextender (self explanatory I hope)
cornerstone.browser
(this is a great utility package for BrowserViews and portlet Renderers
to make form/session/cookie handling much nicer and more standard)TickingMachine (this one could be made redundant with a persistent
utility in the site root and then cron or ClockServer configured to
just call the method on the utility, but frankly, that is really just
duplicating what TickingMachine already does, and z3 style events are
nice)
Of those three, cornerstone.browser is not yet egg-ified (I think)
so it's an svn checkout, and TickingMachine is an old-style product
available via tarball. I have these two both being fetched with my
custom buildout and can supply buildout steps if anyone needs help.
Known Issues:
There's no tests yet (that's why it's in the sandbox currently ;)Probably
there's cruft in various places in the packages as I have spent the
last week refactoring it all out to make it more generally usableIt's complicated and I haven't documented it yet, except in this email :)
Good Stuff:
It
works. A user can sign up to your site, purchase some credit, create an
IOneWeekCreditPublishedContent item, and get a portlet offering to let
them publish it for however many weeks they want. The only thing you
need to do is add a <five:implements ... /> statement to your
ZCML marking your content with getpaid.creditpublish.interfaces.IOneWeekCreditPublishedContent,
and tell the Credit Publishing portlet which content item contains the
price that should be charged for 'one week of publishing'It's egg-ified already (no pypi yet)
I intend to keep working on it as it is for a live and motivated client
So that's it. The code is currently available at:
https://getpaid.googlecode.com/svn/sandbox/dixond/
I'd love any feedback, constructive criticism, svn commits ;), and
most importantly some sort of consensus as to whether this is something
that would be nice to have in the main GetPaid repository as a plugin. [Less]
Posted about 1 year ago by Christopher Johnson
Recap
Last week we learned:
(12:04:11 AM) dixond: effectively what I've built is a way to turn a Plone site with GetPaid into an advertising channel, where people can pay to publish their content for a fixed time. The basic framework and
... [More]
concept can be extended then to other things also.
Stepping down from dixond's elloquent marketing-speak, the use case is something like this: A user needs some credit to make their content public in some way (ie "for a week" or by virtue of a group membership).
OK, the nuts and bolts:
1) ICreditRegistry for storing the credits (can obviously be in RDBMS but my trivial implementation uses ZODB and BTrees)
2) TickingMachine subscriber that knows about ICreditPublishedContent and applies some rules around send reminder emails, depublish, etc
3) Archetypes schema extender profile for ICreditPublishedContent to track stuff like 'weeks remaining published'
4) Various portlets to allow purchasing credit and using that credit to publish ICreditPublishedContent
5) A few basic content types to represent the credit being purchased
Basically, what I've been building is a way to buy 'non-things' much like the notion of the 'donatable' type and to keep track of them and then use them for controlling access to arbitrary actions later. At present it works great, I'm spending most of my time 'generic-ifying' it so that it can be re-used elsewhere and isn't tied too closely to my specific use-case. Also on the list are other credit types like 'group membership' etc. Once I've generic-ified it enough this should be 'easy'.
Currently, three packages: getpaid.creditpublish, getpaid.creditregistry, getpaid.purchasablecredit
Future extensions could also allow content to be accessed by using credits, if a payment processor is implemented which consumes credits.
What are others saying: "that's a really needed usecase of getpaid - lots of people will be hopping happy :)" -duffyd on #getpaid
New stuff
So, it did land in the repo - in sandbox: https://getpaid.googlecode.com/svn/sandbox/dixond/
Here is the full post dixond made (can be found in mailing list archive also):
I have been busy implementing a slightly different sort of use-case on
top of GetPaid for the last couple of weeks. The scenario is based
around a site where the site owner would like to charge the general
public to run, eg, user-submitted advertisements for a fixed period of
time. Think 'classified ads' or similar. The user is put in complete
control of publishing their content according to a policy (eg, the
first one implemented is for week-by-week publishing). The user pays
for a 'week' of credit, and can then consume those in publishing their
own content for that period of time. Also on the cards is
month-by-month group membership, which could then give them access to
special roles etc for 'all you can eat publishing'.
The overall framework is a relatively big, semi-independent
component/app in its own right, but the payment portion of it is tied
quite closely to GetPaid, and the rest seems to me to tie in nicely to
GetPaid as a whole, so I've attached it in name and spirit to GetPaid
for the moment ;)
There are three pieces that I have uploaded code for currently, all
of them relatively divorced from the nitty-gritty implementation
details and specifics of the use-case that birthed them:
getpaid.purchasablecredits
-- This is just a very simple content type with Title, Description, and
Price that acts as a sort of 'meta-product'. Its only purpose is to be
a buyable type that you can put any details in that you want.getpaid.creditregistry -- This is a very basic registry tool to
store 'credits'. The interface could very easily be implemented with
collective.lead in an RDBMS, but the package contains a simple
implementation of getpaid.creditregistry.interfaces.ICreditRegistry
which uses a Persistent utility in the ZODB and BTrees to store the
purchased credits and allow them to be added/removed.
getpaid.creditpublish -- This is where all the action is. A
number of different pieces all collaborate inside here to make
everything hang together:
Event handler that watches for
purchases of content items providing IOneWeekPublishedCredit and
increments the counters in the ICreditRegistry utility appropriatelyPortlet providing the mechanism for purchasing 'One Week
Publishing' credits. It gets the price and description of this from any
content item that implements IBuyableContent - when the portlet is
created it asks for the UID of an item to use for
Title/Description/Price - the 'representative object'Adapter from the IOrder, ILineItem, and 'representative object' to
be able to add credit records into the ICreditRegistry utility
Portlet to allow users to publish/depublish IOneWeekCreditPublishedContent content items (marked with ZCML).schema
extender for items marked with IOneWeekCreditPublishedContent to
provide some utility fields (weeksLeftPublished,
republishedReminderSent)Event handler subscribed to Products.TickingMachine.ITickEvent.ITickEvent:
this handler provides the de-publish/re-publish logic that drives the
time-based publishing. It runs however often you have your ticking
machine set, and runs a catalog search for
IOneWeekCreditPublishedContent items that have expired or are about to
expire and performs various policy logics on them (eg, re-publish for
another week if the user has requested that, de-publish if they are out
of credit, etc)
The various portlets and subscribers are geared currently
to the IOneWeekCreditPublishedContent policy, but there is no reason
other policies can not be added and patterned off the existing one. In
fact I intend to do this for group membership.
Several dependencies are introduced by getpaid.creditpublish:
archetypes.schemaextender (self explanatory I hope)
cornerstone.browser
(this is a great utility package for BrowserViews and portlet Renderers
to make form/session/cookie handling much nicer and more standard)TickingMachine (this one could be made redundant with a persistent
utility in the site root and then cron or ClockServer configured to
just call the method on the utility, but frankly, that is really just
duplicating what TickingMachine already does, and z3 style events are
nice)
Of those three, cornerstone.browser is not yet egg-ified (I think)
so it's an svn checkout, and TickingMachine is an old-style product
available via tarball. I have these two both being fetched with my
custom buildout and can supply buildout steps if anyone needs help.
Known Issues:
There's no tests yet (that's why it's in the sandbox currently ;)Probably
there's cruft in various places in the packages as I have spent the
last week refactoring it all out to make it more generally usableIt's complicated and I haven't documented it yet, except in this email :)
Good Stuff:
It
works. A user can sign up to your site, purchase some credit, create an
IOneWeekCreditPublishedContent item, and get a portlet offering to let
them publish it for however many weeks they want. The only thing you
need to do is add a <five:implements ... /> statement to your
ZCML marking your content with getpaid.creditpublish.interfaces.IOneWeekCreditPublishedContent,
and tell the Credit Publishing portlet which content item contains the
price that should be charged for 'one week of publishing'It's egg-ified already (no pypi yet)
I intend to keep working on it as it is for a live and motivated client
So that's it. The code is currently available at:
https://getpaid.googlecode.com/svn/sandbox/dixond/
I'd love any feedback, constructive criticism, svn commits ;), and
most importantly some sort of consensus as to whether this is something
that would be nice to have in the main GetPaid repository as a plugin. [Less]
Posted about 1 year ago by
Last week, we peered into the top secret skunkworks of dixond and well,
let the cat out of the bag about an exciting new extension coming to
GetPaid any day now :) Ok, so maybe skunkworks is a bit of
exageration...but I deal with
... [More]
developers who are hard to get to talk!
It is often classified (in heads) until checked in...thanks to a
shocking burst of verbosity, we got this insight:
(12:04:11 AM) dixond:
effectively what I've built is a way to turn a Plone site with GetPaid
into an advertising channel, where people can pay to publish their
content for a fixed time. The basic framework and concept can be
extended then to other things also.
Stepping down from dixond's elloquent marketing-speak, the use
case is something like this: A user needs some credit to make their
content public in some way (ie "for a week" or by virtue of a group
membership).
OK, the nuts and bolts:
1) ICreditRegistry for storing the credits (can obviously be in RDBMS but my trivial implementation uses ZODB and BTrees)
2)
TickingMachine subscriber that knows about ICreditPublishedContent and
applies some rules around send reminder emails, depublish, etc
3) Archetypes schema extender profile for ICreditPublishedContent to track stuff like 'weeks remaining published'
4) Various portlets to allow purchasing credit and using that credit to publish ICreditPublishedContent
5) A few basic content types to represent the credit being purchased
Basically,
what I've been building is a way to buy 'non-things' much like the
notion of the 'donatable' type and to keep track of them and then use
them for controlling access to arbitrary actions later. At present it
works great, I'm spending most of my time 'generic-ifying' it so that
it can be re-used elsewhere and isn't tied too closely to my specific
use-case. Also on the list are other credit types like 'group
membership' etc. Once I've generic-ified it enough this should be
'easy'.
Currently, three packages: getpaid.creditpublish, getpaid.creditregistry, getpaid.purchasablecredit
Future
extensions could also allow content to be accessed by using credits, if
a payment processor is implemented which consumes credits.
What
are others saying: "that's a really needed usecase of getpaid - lots of
people will be hopping happy :)" -duffyd on #getpaid
What for this landing in the GetPaid repo any time now! [Less]
Posted about 1 year ago by
Last week, we peered into the top secret skunkworks of dixond and well,
let the cat out of the bag about an exciting new extension coming to
GetPaid any day now :) Ok, so maybe skunkworks is a bit of
exageration...but I deal with
... [More]
developers who are hard to get to talk!
It is often classified (in heads) until checked in...thanks to a
shocking burst of verbosity, we got this insight:
(12:04:11 AM) dixond:
effectively what I've built is a way to turn a Plone site with GetPaid
into an advertising channel, where people can pay to publish their
content for a fixed time. The basic framework and concept can be
extended then to other things also.
Stepping down from dixond's elloquent marketing-speak, the use
case is something like this: A user needs some credit to make their
content public in some way (ie "for a week" or by virtue of a group
membership).
OK, the nuts and bolts:
1) ICreditRegistry for storing the credits (can obviously be in RDBMS but my trivial implementation uses ZODB and BTrees)
2)
TickingMachine subscriber that knows about ICreditPublishedContent and
applies some rules around send reminder emails, depublish, etc
3) Archetypes schema extender profile for ICreditPublishedContent to track stuff like 'weeks remaining published'
4) Various portlets to allow purchasing credit and using that credit to publish ICreditPublishedContent
5) A few basic content types to represent the credit being purchased
Basically,
what I've been building is a way to buy 'non-things' much like the
notion of the 'donatable' type and to keep track of them and then use
them for controlling access to arbitrary actions later. At present it
works great, I'm spending most of my time 'generic-ifying' it so that
it can be re-used elsewhere and isn't tied too closely to my specific
use-case. Also on the list are other credit types like 'group
membership' etc. Once I've generic-ified it enough this should be
'easy'.
Currently, three packages: getpaid.creditpublish, getpaid.creditregistry, getpaid.purchasablecredit
Future
extensions could also allow content to be accessed by using credits, if
a payment processor is implemented which consumes credits.
What
are others saying: "that's a really needed usecase of getpaid - lots of
people will be hopping happy :)" -duffyd on #getpaid
What for this landing in the GetPaid repo any time now! [Less]
Posted about 1 year ago by Christopher Johnson
Last week, we peered into the top secret skunkworks of dixond and well, let the cat out of the bag about an exciting new extension coming to GetPaid any day now :) Ok, so maybe skunkworks is a bit of exageration...but I deal with developers who are
... [More]
hard to get to talk! It is often classified (in heads) until checked in...thanks to a shocking burst of verbosity, we got this insight:
(12:04:11 AM) dixond:
effectively what I've built is a way to turn a Plone site with GetPaid
into an advertising channel, where people can pay to publish their
content for a fixed time. The basic framework and concept can be
extended then to other things also.
Stepping down from dixond's elloquent marketing-speak, the use case is something like this: A user needs some credit to make their content public in some way (ie "for a week" or by virtue of a group membership).
OK, the nuts and bolts:
1) ICreditRegistry for storing the credits (can obviously be in RDBMS but my trivial implementation uses ZODB and BTrees)
2) TickingMachine subscriber that knows about ICreditPublishedContent and applies some rules around send reminder emails, depublish, etc
3) Archetypes schema extender profile for ICreditPublishedContent to track stuff like 'weeks remaining published'
4) Various portlets to allow purchasing credit and using that credit to publish ICreditPublishedContent
5) A few basic content types to represent the credit being purchased
Basically, what I've been building is a way to buy 'non-things' much like the notion of the 'donatable' type and to keep track of them and then use them for controlling access to arbitrary actions later. At present it works great, I'm spending most of my time 'generic-ifying' it so that it can be re-used elsewhere and isn't tied too closely to my specific use-case. Also on the list are other credit types like 'group membership' etc. Once I've generic-ified it enough this should be 'easy'.
Currently, three packages: getpaid.creditpublish, getpaid.creditregistry, getpaid.purchasablecredit
Future extensions could also allow content to be accessed by using credits, if a payment processor is implemented which consumes credits.
What are others saying: "that's a really needed usecase of getpaid - lots of people will be hopping happy :)" -duffyd on #getpaid
What for this landing in the GetPaid repo any time now! [Less]
Posted about 1 year ago by Christopher Johnson
At last the Ohloh report is updated! So here is the update:
11k lines of code19 enlistments (aka different packages/products/libraries)
Contributors report is now updated. Our top five contributors are now:
... [More]
KapilLucieMauritsHoracio
Matt Halstead
One thing I can't figure out is how did we lose about 4k lines of code? I think there either must be something missing in the enlistments -or- pointing at /trunk before indexed some large things not actually part of the code (like the workflow addons...or Five...or...). I tend to think it is the later.
In other news, we are now at 815 downloads of the 0.6.1 release. [Less]
Posted about 1 year ago by
We are building on the momentum of last week's 2 day sprint and the
previous Friday sprints in getting GetPaid super-charged. An amazing
amount of cleanup, organizing and catchup is going on in the community
right now - it is great to see
... [More]
(and Fridays are regular GetPaid sprint
days now!).
We want to continue this momentum and engage new folks - while
taking advantage of a great change to work together in person - at the
Plone Conference in DC in October. We hope you will join us! If you are
interested, please sing up at http://www.openplans.org/projects/plone-conference-2008-dc/getpaid
As we refine more details, we will keep that page updated. In the
meantime, you can get a sense of what we are working on at Friday
sprints (still leveraging the http://code.google.com/p/getpaid/wiki/AugustSprint page for organizing. [Less]
Copyright © 2009 Geeknet, Inc., All Rights Reserved.