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.


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

- 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.

Reply via email to