Around 36 hours ago, I was in a room filled with iframe-related anguish. Now, that is the type of anguish I understand, the type of anguish that inspires me to pursue heroic and illogical projects and/or go on bad-coding benders.
Bad-coding benders are borne out of good intentions. You want to produce a full-fledged solution to replace an obviously faulty, yet ubiquitous approach. You underestimate the scope of the project. You don't consider that to produce a solution that could be plugged into an existing production website you need to spend approximately 10% of the time 'making it work' and then 90% making it safe and user friendly. With that 100% behind you, you also need to face an additional and unforeseen hurdle in spending as much time making it pretty.
Onto the problem! The currently extant solution for integrating Google Forms into Drupal has stopped development in 2011, and its last running version runs on Drupal 6.x. Not good. It is also entirely huge, making use of the SimpleHtmlDOM library for a task that, turns out, might well be handled by cca 12 lines of beginner's PHP.
Q. Why is this good?
A. Allows me to play around with how PHP handles DOM. I have never done this before and just this one little step toward scraping a form when given, say, a Google Form [GF] URL or key without the use of iframes puts me far closer to giving it all the functionality the clients/victims care about - custom stylesheets, the entire shizz being wrapped in a Drupal 7.x compatible module, out-the-box jQuery validation and other prettiness.
To approach this part, I've built a three-step process.
Step 1: Simple form page that allows me to paste a Google Form key and click 'Submit' without a care in the world.
Step 2: A flamboyant PHP script majestically entitled 'parser.php' which does several things in an ugly functional manner. It fetches the $_POST values from step 1, strips them of all ugly and dangerous tags and intentions; it goes on to construct a Google Form URL and scrapes the <form> element therefrom; without any additional hassle (for now) it tries to save the scraped form as a unique .html file in a 'forms' directory; failing that, it passes the form data to step 3 in a $_SESSION variable. Clunky, but workable.
Step 3: Our glorious form is presented here with a fresh stylesheet ripe for dynamic loading.
II. Luckily for my ambitions, my victims' gripes with Google Forms and Drupal don't stop at having to paste the form's iframe in order to get anything done. As many (most) people who love the Google Drive functionality but resent its unfriendliness toward customization (I am not a fan of Google translating everything into the local language, myself), these customers have had to paste the damned form element into their own page, get rid of any and all unwanted elements (hello to the unnecessary and confusing markup!) and style that mess inline.
Q. Why is this good?
A. It allows me to get creative with: stripping unwanted markup from the DOM and making it both accessible and functional; making a custom confirmation page a matter of seconds; ditto for adding a custom stylesheet.
III. The fun doesn't stop there. The true task of this mission is to be able to create a new form straight out of Drupal as a non-technical user. Now, I could more-or-less copy the solution of the previous Google Forms For Drupal Module, or re-code the Ruby solution in PHP, slap it together and pray it works. What this is really good for, however...
Q. Why is this good?
A. If we're already integrating this in Drupal - why stop at painstakingly copying the god-awful creation process of the Gforms? This offers an opportunity for a fun drag-and-drop module [with severe constraints and without using or emulating Masonry] to finally force me into doing something semi-meaningful with JS. It will also mark my first time using AppScript for a somewhat good purpose.
This part requires a full-on Google Form integration, which I'm handling through JSON like a good pupil of the Internet. It also requires building a custom d'n'd solution.
IV. Validation is, I've learned, an issue of some worry to my new unwitting customers. They've been using a validation script which is, from what I've surmised, simultaneously good and tragically outdated. I am reluctant to butcher an honest developer's licensed code, for obvious reasons; yet I'm even more reluctant to reinvent the wheel. I will need to find a good workable solution that's not almost heavier than the damn CMS they're running on.
Q. Why is this good?
A. It's not, but it does force me to find a decent lightweight validation solution which may well be added to my in-a-bind-toolkit.
V. And finally, how's this integrated into Drupal? Here I'm not talking about making it a module - that seems feasible enough, and will be done over afternoon beer - but I do need to make them a convincing enough UI that just *works*. There will need to be options for anything and everything, from saving and previewing forms [making this a custom post type in addition to a giant pain in the ass] to having a reasonably easy multipage solution. All of this is none the less important than the Huge Happy Task of making myself a Google Forms API from wishes and leprechaun tears.
Q. Why is this good?
A. I need to start making modules that are actually useful to people, and not just an adorably ugly learning opportunity on a Stark-grey background. Having a complete publishable module, ie. building stuff that is extendable, valid, accessible and has decent UX will be life-changing.
