|
Re^4: Perl Contempt in My Workplace
by marto (Cardinal) on May 05, 2021 at 12:09 UTC
|
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] |
|
|
You said Perl is no longer of that 20 years ago., and there's a good reason for not doing these things the same way you did them 20 years ago. The front page of the datatables site you linked to shows which data sources are supported, so you couldn't have looked very far. Using the core JSON module to return your data, regardless of its source is all you had to do, no need to 'create yet another CPAN module'. All of your complaints are simply addressed reading the docs of the tool you choose to use (datatables) and using the core perl modules. No need for anything else. You seemed to think it more productive not to do this, but try various CPAN modules which you didn't seem to get working.
| [reply] |
Re^4: Perl Contempt in My Workplace
by cavac (Parson) on May 20, 2021 at 14:39 UTC
|
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] |
|
|
| [reply] |
|
|
|
|
|
|
|
A reply falls below the community's threshold of quality. You may see it by logging in.
|
|
|
|
|
|
|
|
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] |
