what CPAN module should I use for the "server-side processing"?
Why do you need a module? Can you describe what such a module would do?
So you have a web server and you receive an ajax request with all the many parameters needed to fetch the next page of results. If you were using a module and you wanted to provide those parameters and get back JSON, what would the module do? Isn't it only to query the DB and convert the results to JSON? So what should the module do? Wrap up the DB query with some layers of abstraction? By the time you wrote the config needed you could have written the handler directly with DBI.
I admit I often have some custom filtering/ordering code in the ajax route handler that preprocesses the DB query but as I said before I don't see how that could productively be abstracted.
The way forward always starts with a minimal test.
| [reply] |
why I need a module - because I want to stay on shoulders of giants and not reinvent the wheels.
my plan was to find some plugin for Catalyst of Mojo or Dancer or whatever so to have my database "just work" - like in https://datatables.net/examples/server_side/simple.html - just a table but also with excel-like filtering
I agree that productive abstracting could be problematic in this particular case.
| [reply] |
"my plan was to find some plugin for Catalyst of Mojo or Dancer or whatever so"
Contrary to what you said earlier:
"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"
Write a perl script query your database in a sensible way (see previous comments), return the data in JSON format. You clearly haven't read any of the documentation for the tools you've decided to use, suggesting another boilerplate module from CPAN would likely not do what you want, and be a waste of time. Also yes, you are wrong in your assumption about module numbering, and almost everything else you've written in this thread to date.
| [reply] |
Yes, in general. There is nothing semantically significant about a module with a version number less than 1.0.
| [reply] |
Agreed. I have done many projects where version numbering is integer-only. So a Version "1" means it's the first ever version of that module, and probably quite buggy. I used Integers, so i wouldn't have to deal with floating-point bugs in a number of automated deployment and validation scripts.
In my opinion, version numbers only have to do two things: 1) Make sense to the Author. 2) Increase with every version so that PAUSE/CPAN/BackPAN stuff sees them as "newer"
One of the projects i mentioned above is a web/worker framework. When dynamically loading modules (for a specific project), it checks the version number of that module and only accepts it if it's the same version as the framework. So, occasionally, i have to bump some projects version number without any other changes (so looking *only* at that project, some people may be confused). Reason behind this is simple: A new framework version usually has some API changes, so i want to make sure all projects based on that get a once-over when upgrading the framework and i'm not unwittingly running into upgrade woes.
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] |
