LISTS WORKING cleanup afterwords
This commit is contained in:
@@ -7,382 +7,26 @@
|
||||
|
||||
MISC ITEMS THAT CAME UP
|
||||
|
||||
todo: if you change the filter the page should reset to 1 or else you get a weird scenario where it says page 5 but there is only one result page so it says no data
|
||||
todo: tagpicker, don't like how it works, it's funky to enter multiple tags and input doesn't go away when you select it just leaves the typed text there
|
||||
once a selection is made it should not repeat the typed text again, it shoudl be ready to type another tag from start
|
||||
|
||||
|
||||
LISTVIEW REPLACE CURRENT <----HERE not THERE ---v
|
||||
(below this is all past for reference)
|
||||
|
||||
TODO (now)
|
||||
TAGS FILTER ISSUES
|
||||
|
||||
Table query (working)
|
||||
"SELECT acustomer.name, acustomer.id, acustomer.phone1, acustomer.emailaddress, aheadoffice.name, aheadoffice.id, acustomer.tags from acustomer left join aheadoffice on (acustomer.headofficeid=aheadoffice.id) left join acontract on (acustomer.contractid=acontract.id)
|
||||
where (acustomer.tags @> array['violet','yellow'::varchar(255)]) ORDER BY acustomer.name ASC LIMIT 5 OFFSET 0"
|
||||
|
||||
Report Query (not working)
|
||||
"SELECT acustomer.id, from acustomer left join aheadoffice on (acustomer.headofficeid=aheadoffice.id) left join acontract on (acustomer.contractid=acontract.id)
|
||||
where (acustomer.tags @> array['violet','yellow'::varchar(255)]) ORDER BY acustomer.name ASC "
|
||||
|
||||
|
||||
|
||||
todo (after)
|
||||
Test TEST **TEST**
|
||||
Test all column types are properly filterable including ENUMS and TAGS
|
||||
|
||||
Clean up the server and client code including the wierd props not being used set on all list forms etc
|
||||
get rid of the countless commented out lines that are now irrelevant and will just cause confusion in future
|
||||
Duplicate option for filter is no longer required at server routes / biz
|
||||
|
||||
|
||||
|
||||
|
||||
Look for "listview" and get rid of it
|
||||
|
||||
|
||||
|
||||
|
||||
.......
|
||||
|
||||
|
||||
|
||||
How it works:
|
||||
user opens grid for first time this session, client sets filterid to 0/default and triggers fetch of the filter list which in turn triggers getdata
|
||||
GetData 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
|
||||
Appearance
|
||||
Filter icon beside filterable column header:
|
||||
Filtered columns have a highlighted filter icon showing they are filtered (clickable)
|
||||
Unfiltered columns have a duller looking filter icon (clickable)
|
||||
Sort icon
|
||||
uses built in v-data-table sort and sort order icon system
|
||||
Column order / visibility
|
||||
Replace current filter icon with column order visiblity icon and just keep as is in UI of datatable (modify columnview ui as per below)
|
||||
|
||||
ColumnView UI
|
||||
UI opens up to same type of form as current ay-data-list-column-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 filter UI
|
||||
datatable has drop down with list of filters available for the datalistkey, public adn personal, defaults to default
|
||||
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 COLUMN WIDGET
|
||||
filter button beside each filterable column header
|
||||
Ui contains filtering settings for that column and shows existing, basically same as filter portion of existing ay-data-list-column-view.vue
|
||||
has accept / cancel buttons, on accept immediately updates current filter (named or default) filter collection object in it's entirety
|
||||
FILTER DROPDOWN
|
||||
Defaults to default filter on page open
|
||||
has an edit button appended for opening FILTER MANAGER UI:
|
||||
Save, SaveAs (separate), Delete (NOT VISIBLE IF DEFAULT), Cancel, Reset resets current filter to server list default
|
||||
Name box (IF NOT DEFAULT otherwise otherwise goes read only and just shows "-")
|
||||
All users checkbox for shared filters (DOES NOT SHOW if default filter)
|
||||
Thus they can update existing, save working default filter to a named filter
|
||||
On SAVE triggers update of Filter dropdown (which triggers getdata) and exits
|
||||
On SAVEAS it saves as new copy to the server, sets the current filter id to that new filter exits and triggers filter picklist to update itself triggering also getdata
|
||||
On DELETE it updates local filter picklist to remove it, sets the current filter id to 0/default, exits and triggers filter picklist to udpate itself which also triggers getdata
|
||||
on CANCEL it only closes the filter manager UI and does nothing else
|
||||
on RESET it tells teh server to reset the current filter to default via RESET ROUTE , exits and triggers filter picklist to udpate itself triggering a getdata
|
||||
SERVER / GETDATA
|
||||
REQUEST
|
||||
BASE: DataListKey, ClientCriteria, FilterId
|
||||
TABLEVERSION: Limit, Offset : base
|
||||
DataListSelectedRequest: ObjectType(ayatype),SelectedRowIds(long[]) : base
|
||||
REPORT:
|
||||
|
||||
|
||||
RESPONSE
|
||||
when server returns data for table it also includes the sort and filter in effect which is saved locally inside the vm data for use by filter UI (doesn't survive refresh)
|
||||
server applies filter id specified in request if filterid is 0/default then it fetches their default filter (which in turnr makes one if it doesn't find one)
|
||||
|
||||
REFRESH OF DATATABLE PAGE
|
||||
full page refresh / reload causes reset to default filter which triggers the fetch of the data which fills the local collection and sets teh ui for filter sort
|
||||
|
||||
V7 ISSUES FUCKERY AVOIDANCE
|
||||
ISSUES:
|
||||
Byzantine code in v7 the issues with the grid were the byzantine code behind when having to work with so many grid controls, no one control so easier off the bat
|
||||
bad filter causing issues with query, errors, timeouts
|
||||
Solution: server vets the filter and tries to ensure it is sensible so a filter on a nonexistant column should just remove the filter or whatever
|
||||
SOLUTION
|
||||
Basically make validation code have teeth at server; server only ever uses a saved filter so as long as it is saved in correct manner then it's ok
|
||||
if DataList definition updates / changes then server can easily rip through all existing filtes for that table and fixup as necessary by removing no longer columns or renaming if necessary
|
||||
|
||||
|
||||
|
||||
|
||||
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
|
||||
warp the listview to be the default column order and sort method now, remove filters from it is easiest path to proceed, filters are big and require most UI warpage so do them after
|
||||
auto saved behind the scenes with fetch for data if changed as only user changes that
|
||||
currently it's all that's in use since filters aren't coded yet and it's working
|
||||
ACTIONS:
|
||||
premise: DataTable has sort built in from underlying vuetify object but the names it stores are not our column names just "columns.c1, columns.c0" etc
|
||||
can these be changed to be the actual column names somehow which saves a lot of fuckery or else I'll need a translator method?
|
||||
"ColumnView" refers to the Columns visiblity/ prescence, order of columns and sort selections
|
||||
Only location at client that ColumnView data is saved is inside the :options.sync="dataTablePagingOptions" property of the v-data-table itself
|
||||
My code will translate into and out of the grid the ColumnView data for background save and fetch and reset
|
||||
|
||||
columndata and code on getdata coming from server are working code that doesn't need changing it's all about what gets persisted and SENT TO the server on post datalist
|
||||
|
||||
Changes:
|
||||
Modify ay-data-list-column-view.vue to only handle column order and save to the server as the singleton default.
|
||||
No need to persist anything locally in store or session, gzdatatable will pick it up from the server itself on refresh
|
||||
remove all filter and sort aspects so it's only concerned with column order and visibility.
|
||||
Change outer icon from a filter to whatever represents column order selection
|
||||
Modify gzdatatable to fetch the columorder on getdata if it senses it's changed which I'm not sure how to do, need trigger
|
||||
|
||||
|
||||
|
||||
In gzdatatab
|
||||
Do *not* save in session or store or anywhere, just in
|
||||
make a local default for column order and sort and a route to save and fetch automatically
|
||||
could update on same cycle as getdata because it can be compared if changed and saved
|
||||
this would work since get data will be triggered immediately after column order sort change anyway
|
||||
maybe it's more ideal to not have a local saving of it since that's a source of ongoing fuckery in v7
|
||||
and it can fetch it from the server in a flash anyway as it's tiny
|
||||
|
||||
|
||||
|
||||
todo: filter, can be programmatic or user, user saves, can choose from list
|
||||
|
||||
V7 style filtering:
|
||||
Can save with a name
|
||||
Defaults to none
|
||||
if user changes any filters manually it says "Unsaved filter" in selection
|
||||
if code changes filter it goes to "unsaved filter" in selection
|
||||
User can select no filter to get rid of it
|
||||
Basically replicate the v7 ui experience without the shit code behind :)
|
||||
ACTIONS:
|
||||
IN DATATABLE:
|
||||
UnTokenizeListView function deals heavily with filter specific code but almost nowhere else in gzdatatable
|
||||
are the old listview filters actually handled at all since it's more a server concern
|
||||
so that's actually where the bulk of the datatables interest in filters needs to be coded / changed
|
||||
this change is relevant to the new system completely so not wasteful to do that whenever
|
||||
|
||||
|
||||
|
||||
|
||||
Fixup client so existing client works with new filter and sort system *before* porting UI
|
||||
{
|
||||
"dataListKey": "string",
|
||||
"sortBy": {
|
||||
"additionalProp1": "string",
|
||||
"additionalProp2": "string",
|
||||
"additionalProp3": "string"
|
||||
},
|
||||
"filter": [
|
||||
{
|
||||
"column": "string",
|
||||
"items": [
|
||||
{
|
||||
"op": "string",
|
||||
"value": "string"
|
||||
}
|
||||
],
|
||||
"any": true
|
||||
}
|
||||
],
|
||||
"clientCriteria": "string",
|
||||
"columns": [
|
||||
"string"
|
||||
],
|
||||
"offset": 0,
|
||||
"limit": 0
|
||||
}
|
||||
Saved filters and saved default column order / sort
|
||||
Named and saveable Filters are the new listview
|
||||
Column order and sort is just default behind the scenes they don't have to save it on purpose or name it it just persists and they can reset to deffault
|
||||
replace this:
|
||||
[HttpGet("default/{dataListKey}")]
|
||||
public ActionResult GetDefaultDataListView([FromRoute] string dataListKey)
|
||||
Test the everloving shit out of this
|
||||
|
||||
CURRENTLY: most lists default view ok (not filtering yet just default no filter) except:
|
||||
Do *all* reports
|
||||
Do test of bulk ops tags etc
|
||||
Do STATIC and dynamic lists (test them all like a smoke test)
|
||||
MemoList in correct order ? (added a sort that wasn't there originally but seems necessary)
|
||||
ReminderDataList in correct order? ''
|
||||
|
||||
Clean up the server code
|
||||
lots of commented out classes and redundancies and possibly naming re-jigging needed once working
|
||||
seeder line 169 sample filters, replace? Or remove?
|
||||
|
||||
Client: Move on to new datatable form and filter coding at UI
|
||||
First: Check api explorer for new filter format, is it kosher looking to work with client
|
||||
|
||||
UI Widgets dashboard use listView too
|
||||
|
||||
todo: DataList view and filter are combined and this is wrong
|
||||
columnorder / sort should be something changed rarely and static as how people like it
|
||||
Filter should be dynamic and saveable and have multiple variations supported
|
||||
a forced filter (metaView) should only affect the filter portion, not the column order / sort portion
|
||||
This is why I'm running into issues with the metaview stuff conflicting, it's not done correctly
|
||||
|
||||
What is dynamic and user changes a lot?
|
||||
Filter, sort order
|
||||
|
||||
PLAN:
|
||||
SORT
|
||||
surface in front
|
||||
use existing multisort UI by enabling "multi-sort" and removing the sort false setting
|
||||
sort will automatically set the :options.sync="dataTablePagingOptions" and provides the sorted columns and direction (sortBy and sortDesc in arrays)
|
||||
e.g.: { "page": 1, "itemsPerPage": 10, "sortBy": [ "columns.c0", "columns.c1" ], "sortDesc": [ false, true ], "groupBy": [], "groupDesc": [], "mustSort": false, "multiSort": true }
|
||||
|
||||
FILTER
|
||||
surface right up front in grid
|
||||
requires custom functionality
|
||||
don't take up any UI space more than necessary so one click to open a dialog maybe that can work in any device format
|
||||
Filter icon beside column name
|
||||
icon is brighter / highlighted if in effect else grayed / subdued
|
||||
click on icon opens dialog filter UI for that column with similar UI to current listview filter
|
||||
maybe a filter type control for each type of field? Or maybe more efficient to just have one with various templates per type
|
||||
https://github.com/vuetifyjs/vuetify/issues/3102#issuecomment-529046589
|
||||
https://www.front.id/en/articles/vuetify-achieve-multiple-filtering-data-table-component
|
||||
One click to remove all filters
|
||||
Indicator of filtered but not visible columns
|
||||
|
||||
COLUMN ORDER AND VISIBLITY
|
||||
set column order and visibility in back USING EXISTING UI, just strip out filter stuff
|
||||
Saves as a personal default at the server but easily reverted to server default
|
||||
Removed columns don't filter or sort!
|
||||
make sure non visible columns are removed from any saved filter or sort
|
||||
hmm...actually, not sure about above, maybe it needs to indicate extra filtered (but not visible) columns somewhere? "+[filtersymbol]" at end??
|
||||
|
||||
PROGRAMATTIC FILTER
|
||||
DataTable accepts external filter on the fly and replaces internal filter with provided filter but *does not* change the view or sort settings
|
||||
View doesn't change when on the fly filter applied from another form only the filter changes
|
||||
|
||||
DASHBOARD WIDGETS
|
||||
Dashboard widgets will consume the same filters since they use the same datalists.
|
||||
User will select from saved filters for them but can't make one in the widget itself but makes them in the datatable
|
||||
|
||||
DATA / OBJECTS
|
||||
# ListView FORMAT SERVER and CLIENT
|
||||
Current listview is a monolithic object combining filter and sort and column choice
|
||||
todo: Change the listview object format and separate the items so go from this:
|
||||
{
|
||||
offset: 0,
|
||||
limit: 10,
|
||||
dataListKey: "PartInventoryTransactionsDataList",
|
||||
listView: [
|
||||
{
|
||||
fld: "PartInventoryTransactionEntryDate",
|
||||
sort: "-"
|
||||
},
|
||||
{
|
||||
fld: "PartPartNumber",
|
||||
filter: {
|
||||
items: [
|
||||
{
|
||||
op: "=",
|
||||
value: "400735"
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
fld: "PartWarehouseName"
|
||||
},
|
||||
{
|
||||
fld: "PartInventoryTransactionQuantity"
|
||||
},
|
||||
{
|
||||
fld: "PartInventoryTransactionDescription"
|
||||
},
|
||||
{
|
||||
fld: "PartInventoryTransactionSource"
|
||||
},
|
||||
{
|
||||
fld: "PartInventoryBalance"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
TO THIS:
|
||||
See DataListBase.cs for format
|
||||
|
||||
PERSISTENT SETTINGS
|
||||
DataListTable options columns, sortby, filter instead of one listview
|
||||
User can customize the column display and order and it will save it at the server as their personal singular view to that datatable
|
||||
User can create MULTIPLE NAMED filter and sortby combos and save it as a named filter to the server
|
||||
can select and go back to default as needed
|
||||
|
||||
|
||||
# METAVIEW / VARIANT / PROGRAMMATIC FILTERING
|
||||
There are filters users make and filters the program makes
|
||||
Some filters are STATIC and always applied regardless for security or other reasons and those should be done entirely at teh server
|
||||
(IAyaDataListServerCriteria)
|
||||
Memo, Reminders so only can see their own, Reviews filter by role to see more potentially
|
||||
Some filters are DYNAMIC and restrict by columns that the user can control so they replace user filters adn appear as same as user filter
|
||||
user can remove it to see all or adjust it or whatever
|
||||
Some filters are MIXED / INVISIBLE as they require data provided by client but user doesn't see them or control them
|
||||
CustomerNoteDataList
|
||||
potentially more in future so needs support, is ideally solved by metafilter now but if that is being removed need alternative
|
||||
|
||||
CURRENT METAVIEW DATALIST FILTERS IN USE
|
||||
InsideUserDataList (adm-users) STATIC (could use IAyaDataListServerCriteria)
|
||||
MemoDataList STATIC current TO user only uses IAyaDataListServerCriteria already
|
||||
ServiceBankDataList DYNAMIC
|
||||
OutsideUserDataList (cust-users) STATIC could use IAyaDataListServerCriteria
|
||||
ReviewDataList (home-reviews) DYNAMIC (both single and multiple)
|
||||
PartInventoryTransactionsDataList (inv-part-inventory-transactions) DYNAMIC
|
||||
PartInventoryDataList (inv-part-inventory) DYNAMIC
|
||||
* CustomerNoteDataList (cust-customer-notes) MIXED STATIC but with DYNAMIC value currently using metaview but is actually static, however current server IAyaDataListServerCriteria can't accept a customer id so...
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
NOTES: Metaview is used for two different thigns currently:
|
||||
STATICALLY restricting a list to an always required filter like adm-users and cust-users and cust-customer-notes
|
||||
solution is use variant system like picklist
|
||||
DYNAMICALLY restricting a list to an on the fly filter like ShowAll
|
||||
solution is solved by above changes and can provide alterantive filter programmatically any time
|
||||
MIXED restricting a list on teh fly but also support user filtering
|
||||
|
||||
SEEDER
|
||||
sample datalist is whack now
|
||||
|
||||
MODELS
|
||||
Reporting AND bulk ops require data list sort and filter but not columns
|
||||
Grid views require data list sort and filter AND columns
|
||||
Need a base model and combine upwards using inheritance, can still call methods with aparams defined by base type
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
todo: DataList - there are a bunch of props being set that don't exist, for example currentListViewId, dataListFilter, dataListSort
|
||||
remove them with impunity
|
||||
todo: if you change the filter the page should reset to 1 or else you get a weird scenario where it says page 5 but there is only one result page so it says no data
|
||||
todo: tagpicker, don't like how it works, it's funky to enter multiple tags and input doesn't go away when you select it just leaves the typed text there
|
||||
once a selection is made it should not repeat the typed text again, it shoudl be ready to type another tag from start
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user