Best way to connect a spreadsheet to web database [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 2 years ago.

Improve this question

I'm using web based database for which I need to add spreadsheet capabilities to its front end. I was thinking that I could use Google Docs Spreadsheets. Their Google App Script seems to have the functionally that I need. In particular I can use the URLFetch service combined with onEdit events to keep the spreadsheet and DB in sync -- AJAX style. It also allows me a lot of flexibility in constructing, saving, and sharing the spreadsheets

However some things about Google App Script gave me pause. It runs server-side so it's difficult to debug locally. It doesn't have any sort of debugger with breakpoints or stepping. It can't import external modules or libraries. No JSLint. Without these I started getting that "Uh, oh, this is going to hurt" feeling.

So I'm wondering if there's a better way to bolt on browser accessible spreadsheet functionality to an existing web based database? Or are there best practices for getting the most out of Google App Script?

EDIT: These are the potential solutions in order of what would be best for my application:

1. Browser based JavaScript spreadsheet engine. (May not exist.)
2. Python spreadsheet engine module that I can install on Google App Engine. (I haven't seen thi开发者_C百科s either.)
3. An more robust and AJAXian approach to Google Spreadsheets. (See original question.)
4. Open source spreadsheet engines that I can install on EC2. (These seem to exist -- possibly SocialCalc, or Simple Spreadsheet. Recommendations?)

---

We use spreadsheet functionality on a web page, but rather than scripting all the features of a spreadsheet, we use a calculation engine which gives us the programmatic heart of spreadsheet functionality. A calculation engine knows how to calculate hundreds of types of formulas, handle dependencies (and the order between dependencies), cell formatting etc. In my particular case, we use SpreadsheetGear - http://www.spreadsheetgear.com/products/spreadsheetgear.net.aspx

We create a HTML representation of a spreadsheet with cell navigation and various other features using some javascript. When we need the sheet to recalculate (eg F9 in Excel) we send the entire spreadsheet to the server, ask it to calculate everything and then refill the web page representation with the results. This may also write to the database depending on what's on the spreadsheet.

Perhaps I need your input at this point, to see if my answer is not too far off track.

---

So I did dig into this myself, and it did hurt a bit. Here are the particulars:

The bad:

1. You have to use their editor, no JSLint.
2. No debugger. The scripts run server side, so Firebug and other browser tools are zero help. The "View->Execution transcript" and "View->Logs" are a little help. But they don't seem to function in "onEdit" events.
3. The connection to the web goes through their UrlFetch Service which is doesn't have an asynchronous mode. And it doesn't function at all within "onEdit" events: http://code.google.com/p/google-apps-script-issues/issues/detail?id=185
4. They basically have three event types. "onLoad", "onInstall", and "onEdit". In particular I badly missed an "onClick" event.
5. No external library support.

The good:

1. It is real JavaScript, so it functions predictably, and I can use an external JSLint tool.
2. Shallow learning curve. Understanding sheets, ranges, and set/get values are the key concepts.
3. Lots of functionality for manipulating spreadsheet items, formatting, etc.
4. Google Data API Support? I haven't used this, but it looks like the way to go for connnecting to external web resources.
5. Well integrated, scripted updates on my spreadsheet are immediately visible to others viewing the spreadsheet.

Overall this environment has a ton of potential, with lots of UI capabilities, but it still seems to miss on some key functionality for doing real production development.