|
Re^3: Perl Contempt in My Workplace
by vkon (Curate) on May 05, 2021 at 12:01 UTC
|
...but this means I need to do all my heavy-lifting myself, whereas I want be standing on shoulders of giants.
ok, you probably know this http://datatables.net/ better and probably already solved similar tasks
probably it's my fault for not finding a good way in Perl - but for me - 20+-year perler - it wasn't easy to do in Perl but easy to do in NodeJS - that infrastructure is currently better supported | [reply] |
|
|
I'd never used Datatables before, the first page you linked to highlights what can be used as a data source, it's not a perl specific thing. Expecting programmers to write code isn't unreasonable. Adding needless dependencies is a dangerous thing, as NodeJS developers found out to their peril.
Update: "...but this means I need to do all my heavy-lifting myself, whereas I want be standing on shoulders of giants. " that's why JSON::PP is core, you just return the data (from database query or other munging) in JSON format. A more polished end to end process is why this is also part of modern web frameworks like Mojolicious, and why they're such fun to work with, e.g. $c->render( json => { data => $griddata, cols => \@cols } );
| [reply]
[d/l] |
|
|
ok, so basically you're suggesting me to redo all negotiations to Jquery/datatables from scratch using JSON::PP and do a lot of fun with modern web frameworks.
This is exactly what I was trying to avoid, I want to reuse CPAN modules, not create yet another CPAN module version 0.001 which is to be soon abandoned.
my "fun" area is desktop application programming with GUI preferable with a single executable.
I do not use web frameworks at all - this is not my point of interest.
| [reply] |
|
|
|
|
For data heavy applications (especially using databases), you will always have to do a lot of heavy lifting yourself.
As soon as your data goes above a certain threshold for size and/or complexity, a "standard" data handling module (in any programming language) will probably not cut the mustard. Sooner or later you'll end up writing your own SQL statements, throw in some caching and adapt the whole thing to your exact requirements anyway.
For DataTables this is especially true. First of all, the JS part has tons of options and tons of plugins. So, a completely generic backend would have to replicate everything, potentially making it a big mess of spagetti code that moves at the speed of a glacier.
And secondly, if you use paging or scrolling in DataTables, especially in combination with filters and JOINs over multiple tables, this will just not work with some SQL statement thrown together by a generic module. It'll bog down the server and bore the user to death. Scrolling in particular can generate multiple requests per second, so you'd better optimize the heck out of your backend.
Edit: I do have some more or less generic modules for DataTable based listing of any old PostgreSQL table, but it's tightly integrated in my PageCamel framework, so it probably wont be any use to you. But just in case you're interested to see how i did it, it's in the ListAndEdit webserver module.
perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'
| [reply]
[d/l] |
|
|
"For DataTables this is especially true. First of all, the JS part has tons of options and tons of plugins. So, a completely generic backend would have to replicate everything, potentially making it a big mess of spagetti code that moves at the speed of a glacier."
I don't believe this is true, you could write code code to produce these requirements based on options provided via a perl constructor if required.
"And secondly, if you use paging or scrolling in DataTables, especially in combination with filters and JOINs over multiple tables, this will just not work with some SQL statement thrown together by a generic module."
I often find this to be the case in various products, of course your mileage may vary. The user in question is inflexible in terms of this issue however, and efforts to convince them otherwise seems like a waste of time and effort.
Update: slight rewording.
| [reply] |
|
|
|
|
|
|
|
|
|
|
|
|
|
thank you a lot for your URLs!
actually - my request was rather generic (IMO)
I have one large table (10_000_000+ records) and just want it to be displayed - nothing more.
Excel-like search/filtering on multiple columns is all what I needed.
I thought the request is rather generic and was hoping to find a ready solution to the problem.
| [reply] |
