admin/raven-client
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Browse Source
This commit is contained in:
John Cardinal
2021-01-29 18:59:12 +00:00
parent c2b2d4ead5
commit b2740ab4c7
1 changed files with 58 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

58
ayanova/devdocs/todo.txt
View File

@@ -5,9 +5,67 @@
MISC ITEMS THAT CAME UP
How it works:
user opens grid for first time this session, default filter is in effect
grid sends request to server consisting of offset, limit, datalistkey, clientCriteria and Filter id to apply or empty / 0 if wants default server filter
Server gets the filter specified which is either user default or anotehr named filter and is alwasy in the DataListSavedFilter table userid/listkey/default:or:filterid
server responds with same data as now which includes column order so that is handled already but new additional data:
Sort data - so client can modify datatable display to mirror upon receiving data
Filter data - so client can modify datatable display to mirror upon receiving data
these two items are sent back so that the datatable never needs to cache that locally thus avoiding the v7 pitfalls of fuckery related to messed up mismatch
server can fix or modify filters as necessary any time on changes, server can vet filter or sort and make sure it's ok
client can be simpler and doesn't need the caching fuckery
changing filter or sort is simpler at the client, just set it and fetch teh list again to update the datatable UI automatically
ColumnView UI
UI opens up to same type of form as current ay-data-list-view but with only the columns visibility and order settable, no need for names it's user default
after changes just saves as users sole default for that listkey,userid combo easy peasy
Server sends columnorder and sort anyway so no need to do antyhing but trigger a fetch of the datatable data
Filter and UI
User is *always* using a saved at server filter, it's just that it's the default for the datalist if they haven't modified it yet
Server always sends what filter collection is in effect WITH the data which is in turn stored only in a variable in the vue vm, NOT cached in any way
User can select from named filters or default (which is actually a named filter equivalent, just always has the same name "-")
There is no "unsaved" filter, it always saves, just that there is always a default that user doesn't have to name to save a step
Server always uses a filter, either an empty default if not customized yet or a named one but in all cases it uses db datalistsavedfilter
Filter from atop each grid column by clicking a button there which opens FILTER UI
Filter widget Ui contains filtering settings for that column and shows existing
Filter widget UI also has:
Save, SaveAs (separate), Delete (if not default), Cancel, Reset (reset current filter to server list default)
Name box editable if not default otherwise just shows "-"
Thus they can update existing, save working default filter to a named filter
On save it saves to the server the updated filter collection object in it's entirety, on saveAs it saves as to the server and updates the local filter picklist to select it
On delete it updates local filter picklist to remove it and goes back to default
on cancel it does nothing at all as if it waas never clicked
on reset it tells teh server to reset it RESET ROUTE
On any exit from this UI other than cancel it triggers a getdata for the datatable which also returns the freshly updated filter collection as the server sees it
If there is a named filter in effect that name appears in the filter UI to rename during save / accept or save to new filter
If there isn't a named filter then it's their default filter for that column with no name, is still persisted to server when save but under singleton default
server will need to know or make the default and have identified it in db so knows which is which
User wants to filter
Any change to an existing filter results in
user clicks on a column heading filter icon and opens up a filter ui for that column showing existing in effect as well as can modify
this is a mirror of code already in ay-data-list-view.vue form snipped out and local for just that column
user accepts their changes in ui
if it's a named filter then
filter widget saves this one changed column to server
server fixes up existing or makes new filter at server
LISTVIEW REPLACEMENT
columns and sort are a singleton per datalistkey,userid persisted automatically (no alternative "views" just one of these). User can set them or reset them to default.
filter is different: user can persist a filter by name for future selection, sharing with others (public). The default filter is no filter.
Client *never* needs to send the columnview to the server during datalist fetch as it's always there anyway from teh last change by user or default
and the server drives teh visible columns back at the client when it retunrs the data so the client doesn't care in the grid actually about waht columns are visible or order etc
However, sort is a different matter perhaps so the server also needs to return the sort order to the client of the visible columns
So the client's columnview changes are only of concern to send to the sever to persist, the fetch of that list will return the relevant info
todo: Server needs to return *with* the datalist payload the existing stuff but now also:
Sort order applied
filter applied too
todo: column order and sort disentaglement from "filter" is first order of business