You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From initial Lute v1, I wrote a fancy thing that generalizes queries for DataTables. In v3 it's lute.utils.data_tables.py. This let me write a general handler for getting and rendering data for datatables in the front end.
The downside is that the code is hard to parse, it makes adding new things a bit trickier, and it couples the backend to the front end, so that new things like APIs are harder to write.
The book listing (and the term listing, later) should do something like take a post GET of parameters and return data. The processing of that should be more decoupled from datatables (and the various datatables helpers).
The text was updated successfully, but these errors were encountered:
potentially parse the search string in the routes, pulling out special words. e.g. something like "tag:blah cat" would search for tags named "blah" with the string "cat" in the other searchable fields.
This is a code improvement.
From initial Lute v1, I wrote a fancy thing that generalizes queries for DataTables. In v3 it's
lute.utils.data_tables.py
. This let me write a general handler for getting and rendering data for datatables in the front end.The downside is that the code is hard to parse, it makes adding new things a bit trickier, and it couples the backend to the front end, so that new things like APIs are harder to write.
The book listing (and the term listing, later) should do something like take a
postGET of parameters and return data. The processing of that should be more decoupled from datatables (and the various datatables helpers).The text was updated successfully, but these errors were encountered: