diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index 8b3061df..1929abd2 100644 --- a/ayanova/devdocs/todo.txt +++ b/ayanova/devdocs/todo.txt @@ -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