What Dave S. said is key > > "*If you had insight into what the users were looking for during their > examination of the data*, you may be able to provide a better query that > could *simplify the data presentation*."
Sit down with your users and find out what it is that they *actually* need to get their jobs done efficiently. Really take the time to work with them to understand what they're doing and why. If they're needing to take hundreds or even thousands of rows and mess with them in Excel then they're clearly not being given the information they actually want/need. You might be able to come up with improved Stored Procedure, queries or DB Views that run faster but more importantly you can come up with improved processing and presentation which is what ultimately matters. tldr; Be careful with this > "I'm teaching them to use a central too and database and *do not export > it into a tool like Excel to manipulate the data to see "exactly" how they > want them."* if you aren't giving them something that is at least pretty darn close to what they want, or more importantly need, then you're going to have a hard time winning them over. They won't give a hoot if it is a central tool with a fancy database if it isn't more usable and a clear benefit to them vs Excel, which, lets be honest, lets people do a whole lot and feel in control. If instead you can give them a system where what they're shown is immediately actionable that'll get them interested. Then when they see that they didn't have to mess around in Excel, there aren't any more problems with weird errors popping up because somebody overwrote the vital formula in BJ:59 or a range changed messing up their summaries and they don't have to remember how they set things up last time then they'll really be sold. At that point they probably won't even care if the database took 5 seconds to get the data because you just saved them 10+ minutes of fiddling with Excel just to get started doing their job. ;) Why use web2py over flask, bottle, asp.Net or whatever if you've got to use JavaScript stuff for display too? Well lets be honest, a lot of picking frameworks really just comes down to personal preference because ultimately they can all do the job. I happen to think that web2py is great because it is full stack with pretty much everything included, yet isn't overly opinionated, it's very easy to learn and work with and most importantly I can get new screens/features up quickly. I really like having a DAL instead of an ORM because it just seems more sensible to me, others may not, and some like you who have to use Stored Procedure might be left out (though the ability to easily use executesql to run custom SQL or Stored Procs is another benefit of the DAL). The views system works well when good old HTML is enough but you can also easily create the JSON you need to drive newer JavaScript based stuff when needed. The FORM, SQLFORM, and the grid/smartgrid are great, sometimes magical, especially when you're just wanting to get something basic working quickly. But for some uses, which unfortunately seems to include yours, those built-in grids aren't the end-all, be-all and you really are better off with one of the client-side JS grids that have been mentioned. Fortunately, web2py's still great for getting the raw data, doing some server-side manipulation and transforming it into the JSON that the JS grids, or something like AngularJS, need. On Thursday, December 1, 2016 at 7:10:32 PM UTC-6, Dave S wrote: > > > > On Thursday, December 1, 2016 at 11:08:18 AM UTC-8, Gabor Nyul wrote: >> >> First of all thanks for the hints. >> So it means that the web2py's integrated grid will not be suitable for my >> needs. Bad luck. :-( >> Then here is a stupid and somehow provocative ( :-) ) question: What is >> the value add of web2py (compared for example to flask or bottle) if in >> every case I have to use an external javascript library like Datatable, or >> slickgrid, or Tabulator? >> >>> >>>>> > *Every* case? > > Answer 1: For many cases you can use the bundled tools. Your case isn't > typical, it seems, because of the processing time your queries require. > The normal case for pagination is to use ajax to update the table, with > the query having a limitby stipulation; this is typically fast enough for > most people. Improvement can be done by using caching, but the size of > your results may make caching impractical. > > Answer 2: web2py provides a simple backend that often can get a website > done quickly. The default frontend tools provide a good starting point for > Datatables provides advanced frontend features that can be used to make > the user experience feel more like a spreadsheet. Your users in particular > may appreciate that, since they are manipulating the data presentation. > > If you had insight into what the users were looking for during their > examination of the data, you may be able to provide a better query that > could simplify the data presentation. But perhaps there is no pattern > shared by the different users, and you'd end up with a separate query for > each user. > > /dps > > > > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- 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 web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
