We Keep Coding

Making a Google Form which has a table for answer submission

I'd like to replace a parts requisition process at my workplace with a simple (and cheap to implement) electronic process, initiated using a Google Form. The problem is that I would like users to be able to enter multiple parts (along with associated info, e.g. quantities required, booking references etc.), but I want to do so without having to have multiple repeated questions.
I have researched this extensively and cannot find anything which fits the bill - my thoughts are to use Google Apps Script to create a table in the form which a user can fill-in. The closest I have found is something like this: Creating Form Elements Dynamically
The original paper form looks like the below - I would like the table to request the information as shown below in a similar format:
Thanks in advance!
EDIT! To make it clear, I'm happy to consider other solutions to run this process through an online interface - I have gone for Google Sheets/Forms in the first instance as they are already well integrated within my company and I have experience of them (setting-up triggers etc is pretty simple)

I understand the OP has probably long moved on from this problem. I however have done something along these lines in the past and thought I'd share my approach with the community.
I'll start with the premise Google forms are just good ol' plain HTML forms that users programmatically generate with their form builder. Therefore it's possible to traverse the as-built form and extract both submit location and all field names:
document.querySelectorAll('form').forEach((x) => {console.log(x.action)})```
document.querySelectorAll('[name^="entry."]').forEach((x) => {console.log(x.name + '=' + x.closest('[role="listitem"]').querySelector('[role="heading"]').innerText)})
The above snippet will give you an idea of what the components are.
All that's left after is to build a front end to your requirements with the framework of your choice (I used AngularJs at the peak of its popularity) and incorporate as much or as little UI and validations into it as you desire.
Here you've got the flexibility to either submit the whole thing as one JSON, or to parse it into individual fields and submit entries one by one, for purposes of this demo I opted for the easiest way but this thing surely's got the potential.

Best practice for handling errors in forms submitted via ajax?

I'm wondering what is considered best practice for dealing with forms submitted via ajax. Specifically, I'm wondering what is the best way to handle a form which contains errors.
I see two possible options upon submitting a form with errors:
A. The server returns a JSON document of name value pairs of fields names / error messages. This would then need to be processed client-side and the form would need to be altered by prefixing each field with it's error message and changing the form's styling (adding an error class to the fields for example).
OR
B. The server simply returns a new HTML fragment containing the form with error messages and styles pre-applied. No need to process anything client-side except swap-out the form.
To me option B seems like the easier/quicker option but I can't help but feel that it isn't 'best practice'. Is there pros/cons for either method?

Separation of logic is a huge one here I reckon.
As a project grows, you generally have a front-end team and a back-end team. Imagine the website gets a huge makeover but the logic stays the same. Option B is harder to change the style when the layout is enforced server side.
The application logic (which is this case is server side validation) should be separate from the presentation layer (which is this case is the html/css rendered by the browser).
But at the end of the day, we get paid to produce results so if your not trying to win an academy award for best quality code, and you got bills to pay, just get it done the quickest way.

I'd go with the first option.
The second option just increases the load on the server ... which you always want to avoid. Plus, I feel that if the styling was done on the server-end, the your website isn't exactly modular ... all styling should be done on the front end only.

This is sort of an opinion question but there are a few objective things to say about the topic. Your first option, the pure JSON choice is best used for apps that focus on speed an keeping HTTP requests as small as possible.
The other option, to process your form server-side then return the new form through AJAX doesn't seem to have too many advantages to me. If you're going that route then why bother with AJAX at all? Why not just do a regular form post to the server?
I usually prefer a front end validation and server-side verification. This way you can avoid a JSON call at all if things aren't valid but just in case someone sneaks something in there the server-side code will verify.

I would establish a JSON scheme for validation on the front end. Just basic stuff like what you're checking for on each field, which fields are optional, etc... That gets baked into every page with a form on it. Then let your front end devs pre-validate to avoid unnecessary calls in whatever way makes the most sense to them.
Pre-built errors isn't against any best practice I'm aware of and it's not a terrible way to go (people tend to throw the UI manual of style out the window when it comes to forms anyway), but sometimes you'll want to give more specifics or different errors for different problems.
Always aim for having your cake and eating it too, IMO.

Equivalent of SPContet.Current.ListItem in Client Object Model (ECMAScript)

I'm integrating an external application to SharePoint 2010 by developing custom ribbon tabs, groups, controls and commands that are made available to editors of a SharePoint 2010 site. The ribbon commands use the dialog framework to open dialogs with custom application pages.
In order to pass a number of query string parameters to the custom applications pages, I'm therefore looking for the equivalent of SPContext.Current.ListItem in the Client Object Model (ECMAScript).
Regarding available tokens (i.e. {ListItemId} or {SelectedItemId}) that can be used in the declarative XML, I already emitting all tokens, but unfortunately the desired tokens are not either not parsed or simply null, while in the context of a Publishing Page (i.e. http://domain/pages/page.aspx). Thus, none of the tokes that do render, are of use to establishing the context of the calling SPListItem in the application page.
Looking at the SP.ClientContext.get_current() provides a lot of information about the current SPSite, SPWeb etc. but nothing about the current SPListItem I'm currently positioned at (again, having the page rendered in the context of a Publishing Page).
What I've come up with so far is the idea of passing in the url of the current page (i.e. document.location.href) and parse that in the application page - however, it feels like I'm going in the wrong direction, and SharePoint surely should be able to provide this information.

I'm not sure this is a great answer, or even fully on-topic, but is basically something I originally intended to blog about - anyway:
It is indeed a pain that the Client OM does not seem to provide a method/property with details of the current SPListItem. However, I'd venture to say that this is a simple concept, but actually has quite wide-ranging implications in SharePoint which aren't apparent until you stop to think about it.
Consider:
Although a redirect exists, a discussion post can be surfaced on 2 or 3 different URLs (e.g. Threaded.aspx/Flat.aspx)
Similarly, a blog post can exist on a couple (Post.aspx/EditPost.aspx, maybe one other)
A list item obviously has DispForm.aspx/EditForm.aspx and (sort of) NewForm.aspx
Also for even for items with an associated SPFile (e.g. document, publishing page), consider that these URLs represent the same item:
http://mydomain/sites/someSite/someLib/Forms/DispForm.aspx?ID=x, http://mydomain/sites/someSite/someLib/Filename.aspx
Also, there could be other content types outside of this set which have a similar deal
In our case, we wanted to 'hang' data off internal and external items (e.g. likes, comments). We thought "well everything in SharePoint has a URL, so that could be a sensible way to identify an item". Big mistake, and I'm still kicking myself for falling into it. It's almost like we need some kind of 'normalizeUrl' method in the API if we wanted to use URLs in this way.
Did you ever notice the PageUrlNormalization class in Microsoft.SharePoint.Utilities? Sounds promising doesn't it? Unfortunately that appears to do something which isn't what I describe above - it doesn't work across the variations of content types etc (but does deal with extended web apps, HTTP/HTTPS etc).
To cut a long story short, we decided the best approach was to make the server emit details which allowed us to identify the current SPListItem when passed back to the server (e.g. in an AJAX request). We hide the 'canonical' list item ID in a JavaScript variable or hidden input field (whatever really), and these are evaluated when back at the server to re-obtain the list item. Not as efficient as obtaining everything from context, but for us it's OK because we only need to resolve when the user clicks something, not on every page load. By canonical, I mean:
SiteID|WebID|ListID|ListItemID
IIRC, one of the key objects has a CanonicalId property (or maybe it's internal), which may help you build such a string.
So in terms of using the window.location.href, I'd avoid that if you're in vaguely the same situation as us. Suggest considering an approach similar to the one we used, but do remember that there are some locations (e.g. certain forms) where even on the server SPContext.Current.ListItem is null, despite the fact that SPContext.Current.Web (and possibly SPContext.Current.List) are populated.
In summary - IDs are your friend, URLs are not.

Automating Web of Knowledge H-index output

I'm a research student looking to compare the H-indexes (a measure of how often a scientist's work has been cited by others) of a comma-separated list of people. Web of Knowledge has a javascript form that lets you enter the author's name (field) and their institution (radio button). The h-index is then given as html. How would I go about automating the search and culling out the h-index value for each researcher?

One fairly simple way would be to write a script that uses curl to simulate a submission of the form over the data set you want to use. You'll need to know the form type (POST or GET) and what the parameter names are, then you can fill them out, feeding in data from the command line, a file, or a constant to your script.
The only trick here appears to be that Web of Knowledge will require you to authenticate to use this form.

jQuery form generation

I'm basically looking for the client-side equivalent of Django's ModelForm: I want to be able to specify the general schema of my data (what the fields are, which ones are required, what kinds of fields to use, etc.), and I want to be able to dynamically generate the form, itself, fill it with any initial data, validate it, and extract an object containing the validated data that I can Ajaxily submit places when the form has been filled out.
Dos this exist? Something jQuery-flavored would be preferred.

You might also check out Alpaca (http://www.alpacajs.org). It's similar in some ways to Joshfire's JSON Form library. It uses JSON Schema and features a JSON-based way of specifying your layout and additional rendering options. It also uses templates for flexibility.
You can register your own controls for different data types. It comes with a whole bunch of controls already defined for things like simple text entry all the way to Google Maps and more.
Best of all, it's open-source and based on jQuery. It's been around for the better part of two years and we've been using it with Cloud CMS at my company. (disclaimer: I'm biased + I haven't tried any of the other tools suggested, they're likely awesome as well)

http://neyric.github.com/inputex/examples/json-schema.html
This is very likely what you want. Give YUI a whirl ;)

May I also humbly suggest Metawidget? It supports a broad range of back-end definitions and UI frameworks.

Joshfire's JSON Form library does just that.
It uses the IETF standard JSON Schema format to describe your models, and it can validate your data against it using JSV.
It lets you specify the form layout, but it generates a default form if you don't.
It's based on JQuery.