Brian,
In fact this is already done. I have a complete specification of each
report.
Just to give you an example: We are a railway company, having several
hundreds of train per day. There are a lots of modifications (above 60%,
Don't ask why) to the original plan where we are assigning the engines and
the staff.
The planning staff needs a report to see for the coming month all the
tracks and track segments, with all the statuses to be able to react
(definitely assign or remove/reallocate resources, etc.).
So from the UI point of view even the paging is bad as they have to
smoothly scroll among the data.
2016. dec. 2. 7:54 ezt írta ("Brian M" <bmere...@gmail.com>):
> 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 a topic in the
> Google Groups "web2py-users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/web2py/Re4SUDrq1HQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> web2py+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
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.
