JavaScript grid editor: I want to be Excel (updated)
roberto.open-lab.com
roberto.open-lab.com
It's very tempting: clients love datagrids because they know how to use them. You might like them because they're simple to plug in and provide tons of functionality you don't want to hand-code.
Multiple times have we implemented datagrids as the main UI of an application only to regret it later. Clients expect it to do everything Excel does, and are frustrated when that's not the case. Or they want to sort on a column that makes no sense to have in the datagrid, but if it's not in the grid you can't sort by it. And some of the implementations can be a nightmare to maintain beyond the common cases -- looking at you, ExtJS Grid.
More often than not, you can write a UI that serves the customers needs better and still meets their usability goals. And if they want to report on their data, allow them to download a daily dump in CSV format. Then they can do their Excel reporting without introducing a datagrid into the app.
If you're writing a web-app, you can relatively easily create a new spreadsheet-per-account on the fly, set it up with the right-structure, and just let the user do whatever they want. Periodically you can check the format/content and tell the user if something is invalid (missing column header, missing row data etc.) When everything is ok, the user hits save and you grab all the data from Google using their API. The best part is that each Google Spreadsheet comes with history so if a user doesn't screw something up, they can revert to an older version that worked instantly. Of course, you have to write your code to handle such features.
Has anyone gathered some experience with both (JS + Flash DataGrids) and could tell me how they differ in performance (average load time, memory usage), compatibility (like browser-versions) and stability ?
(Most interestingly: Huge loads of Data. Flash gets slow, but doesn't crash. Google Spreadsheet for example, does)