We at our company have been using web2py for almost 4 years now. We use it as a basis for a wide-spectrum management system for our entire business, as an intranet web-app. We started by implementing a bidding process (generating budget-proposals, and such) as a substitution for monstrous spreadsheets. Granted, that is a very non-trivial accomplishment, and has little to do with the back-end web-framework. The most difficult aspects of such a system, are usually in the front-end, as it needs to do a lot of non-trivial things client-side, while still retaining the spreadsheet benefits. For this, we decided to build on-top of an existing front-end framework. After some research, we landed on a proprietary solution called "EJS TreeGrid": http://www.treegrid.com/treegrid/www/ For what it gave us, it paid for itself about a thousand times over... We chose it mainly for the solidness and flexibility of the API, and the quality and breadth of the documentation, as well as it's feature support. I can talk for days about it, but this would be vastly OT here. Suffice it to say, you need something like this if you are serious about replacing a " monstrous spreadsheet" process. Things like being able to flexibly define trees and/or grids with pivot-tables, a built-in undo/redo, pagination, defining callbacks for anything, etc. We also use it as a replacement for MS-Project, as it has full-support for Gantt-charts, resource-utilization-graphs, as well as run-charts for scheduling.
We are currently experiencing performance issues, but profiling shows that the database is the bottleneck, as noted here. So, it really isn't a question of the back-end web-framework when it comes to such considerations - other factors matter much more. That said, in order to be able to focus on the other important things, you need a web-framework that would require the least amount of effort on your behalf, and in that web2py excels. You want a framework that would get out of your way when implementing front-ends, and help you out as much as possible when defining your data-schema, with little-to-no restrictions. Granted, web2py has a lot of focus on "the simple things", like SQLFORMs and such simplistic-automation, but it doesn't mean you "have" to use them (we rarely do), as once things get a little less trivial, the restricted-nature of such things starts to show. So, to conclude, use what you *need*, not *necessarily* what *exist *in the framework - whatever it may be - and try to properly situate where considerations should focus for each need - some may not be the web-framework (at least not directly). -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
