#summary Summary of ideas and information about making a GetPaid / PloneFormGen integration
#labels Phase-Requirements

= Introduction =

PloneFormGen 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 Details =

Specific use cases: 

 1. 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 PloneFormGen ==

PloneFormGen 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)