IntroductionPloneFormGen is a popular tool for creating custom forms in the Plone CMS. GetPaid could leverage this flexibility to allow Plone site admins to create custom forms associated with the buyable content (or donations) available in their site. Something along the lines of the Salesforce connector done by One/Northwest would be ideal. General scenario would be something like: - Make a form with fields using PFG.
- make the PFG form "buyable"
- Map the fields in form into the checkout wizard fields
Use Case DetailsSpecific use cases: - GetPaid Checkout Form: Make an alternative, single page form that can customize (add new fields to, reorder, change field titles etc using PFG). This is actually a subclassed PloneFormGen that is set up with the prepopulated form.
2. GetPaid cart generating form: ability to map fields to buyable items in your site (show list of items for sale and let user enter quantity, or, in case of a donation, amounts).
3. (??I don't know what this is saying!) ability to add buttons to "checkout" or "add to cart" (customizable names), based on what the user wants to do with the gathered information.
Background on PloneFormGenPloneFormGen info: - PFG "adapter" is Action: first class portal content object. Shouldn't show up in search results.
- Field is part of validation process, but action only called after validation process (ie no validation on action). Actions can be conditional (ie show Thank you page if all fields are validated successfully).
- Goal of PFG: Keep things simple. Skeleton of field and action adapter are simple. If need new hooks, Steve can add. In future, rearchitecting PFG for more Zope3 use. AndrewB wants to make PFG viewlet in future.
- Can use field sets in PFG to improve usability (reflect groupings of getpaid forms).
- Hand off validated data to the action. No return value from the action...actions called in series. If thank you page defined, traverses to Thank you page. Adapter action doesn't have notion of failing - only fields can deal with that - so this may need to be added
Integration Tasks- New method in order generation process: The order is generated by a method that takes the field objects from the wizard and creates the form. We need to be able to create those objects from keyword arguments that can be passed in.
- Slight Refactor checkout wizard: May or may not need slight change to order generation to acknowledge the method changes implied by the new method mentioned above.
- PloneFormGen:
- Enable possiblity that Actions can fail. Currently PFG actions are called in series and can't fail. Steve will do for next minor PFG release. (SteveM)
- getpaid.formgen:
- Create prepopulated form that has all the required fields that will post to the GetPaid checkout process. This checkout form can be added to PloneFormGen form folder.
- PFG action field that stuffs field data into GetPaid machienary: chain of actions: Action 1: add to cart; Action 2: checkout; Action 3: rerender page with portal status and error message (this may not be any extra work...PFG may do it for us)
- Thank you page is handled by GetPaid (anything marked with interface can be the Thank You page). Set up GetPaid's Thanks you page as default for the form.
- If SSL is set in GetPaid admin, then the form renders securely (it is a page where credit card info is entered!). Secure emailing should be forced for PFG when used as a checkout form.
Older notes: split order creation part from data gathering (wizard) Perrito (horacio) here:
If I am not mistaken, the order creation and the processor authorization and perhaps other end of transaction related stuff is happening in the make_payment step in checkout-review-pay of the wizard. I thought that, instead of this, we could have a Class managing all these functionalities with helper methods and, more important, separated from checkout wizard. This way we could use the data gathering method that we want or modify the checkout process without fear of breaking functionality while changing view.
- creating adapter and mapping
- creating item in cart from field (and arbitrary amount)
- mapping dropdown of amounts into the cart (ie pick predefined 5, 10, 20)
- Make a PFG content type that provides prepopulated and mapped form (optional, for usability and not having to recreate all fields)
|
Sign in to add a comment
Interest expressed in this by:
SteveM, father of PFM, has also been told about this and has expressed interested to help :)
Now working in http://mercurial.intuxication.org/hg/getpaid-formgen . DanielHolth can add new authorized users.
Some notes from my intitial quick testing:
Wow! Pretty cool.
Payable item needs to be not the form itself, otherwise the "buyable" portlet shows on the form. Perhaps this portlet could be suppressed? Otherwise we have to create "stub" payable objects.
For form-powered donations, payable item currently needs to cost $1, and the form provides quantity. This is a bit indirect/confusing, it would be nice if the payable item could acquire its price from the form, rather than its quantity. This would let us show cleaner results to the end-user.
Don't want to show orders to user after being placed. That's TMI. Maybe just the order confirmation as the thank you page. One less click. Needs to be site-admin-editable. We should really show the form thank you page, not the getpaid thank you page.
Need a year/month AT widget for credit card date (no day of month), or an option to suppress the day of month in the current AT widget.
Note: i didn't test against real world payment processors
Very excited to see this development! Jazkarta would also be interested in this for accepting payments for training sessions.
I added getpaid.formgen to the getpaid.googlecode.com/svn repo.
Per jonstahl's comment above re: portlet suppression, I've create an issue: http://code.google.com/p/getpaid/issues/detail?id=236