Hi all, In case you click on that link at top in last couple days, it doesn't work...we lost the last 15 or so posts on the blog. I republished the info here: http://plonegetpaid.com/updates/archive/2008/09/10/more-on-getpaid-credits-products/view
dixond would still love some feedback, so have a look in the sandbox! dixond - one helpful tip would be how to install it...and how to get started using it :D Thanks again for sharing! Cheers, Chris On Wed, Sep 3, 2008 at 10:36 AM, Darryl Dixon <[EMAIL PROTECTED]>wrote: > Hi All, > > As per: > http://www.plonegetpaid.com/updates/archive/2008/09/02/exciting-incoming-addition-to-getpaid-credits/view > > 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: > > 1. 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. > 2. 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. > 3. getpaid.creditpublish -- This is where all the action is. A number > of different pieces all collaborate inside here to make everything hang > together: > 1. Event handler that watches for purchases of content items > providing IOneWeekPublishedCredit and increments the counters in the > ICreditRegistry utility appropriately > 2. Portlet 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' > 3. Adapter from the IOrder, ILineItem, and 'representative object' > to be able to add credit records into the ICreditRegistry utility > 4. Portlet to allow users to publish/depublish > IOneWeekCreditPublishedContent content items (marked with ZCML). > 5. schema extender for items marked with > IOneWeekCreditPublishedContent to provide some utility fields > (weeksLeftPublished, republishedReminderSent) > 6. 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: > > 1. archetypes.schemaextender (self explanatory I hope) > 2. cornerstone.browser (this is a great utility package for > BrowserViews and portlet Renderers to make form/session/cookie handling > much > nicer and more standard) > 3. 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: > > 1. There's no tests yet (that's why it's in the sandbox currently ;) > 2. 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 usable > 3. It's complicated and I haven't documented it yet, except in this > email :) > > Good Stuff: > > 1. 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' > 2. It's egg-ified already (no pypi yet) > 3. 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. > > many regards, > Darryl Dixon > Winterhouse Consulting Ltd > http://www.winterhouseconsulting.com > > > > > -- Cofounder and CEO ifPeople - Innovation for People www.ifpeople.net t: 678-608-3408 130 Boulevard NE, #6 Atlanta, GA 30312 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "getpaid-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en -~----------~----~----~----~------~----~------~--~---
