#Psuedoowoofoo Application (Clone of Wufoo Form Builder)
This is a rails application that dynamically generates HTML forms based on user input with jQuery UI and AJAX interaction with server. Integrates with SendGrid, allowing for forms to be emailed to multiple targets. Forms may be routed to customer's own servers or the app's servers, which allow for analytic support.
This project was primarily an exercise in meta-programming, specifically as practice in two areas: (1) use of ruby/rails helper methods to construct dynamically construct dom elements and (2) persisting style elements throughout and applying those elements to a given form in various contexts.
The forms (both the raw code and rendered versions) are generated by a call to a single method. The method ("generate_form") resides in a module, is passed a single "form" object and itself consists primarily of a single call to “form_for.” Within that block, helper methods generate header and footer methods. The various input fields are generated by calling send, with the first parameter being “form_for” helper method name (e.g., “check_box_tag”, “text_field_tag”, etc.). Future plans include support for storing form responses on the app's servers, basic analytics, and a file upload field (likely supported via the “file_field_tag” helper method).
The user can select both layout and color/font stylings separately, allowing them to apply them in various combinations. The user applies these stylings in the "edit form" screen and can then persist the changes by pressing the "Commit the current format." The selected stylings were persisted as strings (e.g., "Color 2" and "Layout 2"). When a form is loaded for display in the main app (that is, either in the index view or in the edit view) the form_generate calls two helper methods: generate_style_hashes and apply_styles_to_html. The generate_style_hashes function takes a form object (which contains the color and layout strings) and returns a hash which maps the color and style elements to various DOM elements. An example style hash output is reproduced below:
{"style-header"=>"background-color: #E8C5B1;
font-family: 'Allerta', Helvetica, Arial, sans-serif;
text-align: center;border: 2px solid black;width:100%;
", "style-ul"=>"background-color: #5E8B7F;
padding:10px;border: 2px solid black;
padding-top: 15px 0;border: 2px solid black;
", "style-li"=>"background-color: #E8C5B1;
font-family: 'Crimson Text', Georgia, Times, serif;
list-style:none;padding:10px;border-bottom: 2px solid black;"}
This style hash, along with the formatted html string (which was produced by calling the form_for method in prior steps of the generate_form method) are then passed to the apply_style_to_html helper method. As the name suggests, this method inserts the hash values inline at the DOM elements which have the corresponding key values. So, in the above example, "background-color: #E8C5B1; font-family: 'Crimson Text', Georgia, Times, serif; list-style:none;padding:10px;border-bottom: 2px solid black;" would be inserted inline in a style tag at the DOM class "style-li".
A similar method is used when styling the email forms. Although not ideal, the inline styling was necessary (especially with respect to the index page). This is because style tags that reference classes must be inserted in the head tag. Unfortunately, multiple forms have to be simultaneously rendered on the index page, and inserting the style tags into the head element of each form is not valid syntax. Therefore, had I used a style tag in the head, I would have had to uniquely identify each form in the page's head tag. While this could have been accomplished by string manipulation (e.g., inserting the form's id as part of the style tag's class references, and doing the same in the form's class tags), I thought that separating out the logic between form generation and style would be cumbersome. Indeed, separating out the dynamic jQuery logic in the edit form field from the persistence layer (and re-generating the styles from that persistence layer) led to difficult complications, resulting in a slight divergence between how the styles are represented on the edit page and how they are represented on the index page.
Available at www.formcreatorapp.net
New users should input an email and then log into the site. One then needs to create a header. Specify (1) the Form Name, (2) a description of the form, (3) the target url (i.e., where the form will be sent), and (4) the form's method (currently limited to either Get or Post).
On clicking "Save edits to the form's header", the basic header should be transferred to the field on the right side of the screen. To add a new entry, press "Add a new entry". A drop-down menu should descend. Users can then enter the entry's 'name' and the label which will appear. The radio buttons determine the type of the entry, which in turn determines which fields are available for the user to fill in. For multiple choice, checkboxes, and dropdown inputs, the user can dynamically create/delete selection options. To save a form, click 'Save this entry.' It should appear on the right side of the screen.
To subsequently edit an option, double-click on it as it appears on the right side of the screen.
Users can select a Form and a Layout using the form and layout buttons on the right side of the screen. To persist the selection, press "Commit the current format." To view all of one's forms, a user can press the button in the 'See Your Forms' div. On that page, users can email the forms, code, or both to themselves or others.
Describe and show how to run the tests with code examples.
Shawn Oakley (shawnoakley@gmail.com)
A short snippet describing the license (MIT, Apache, etc.)