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

Browse Source
This commit is contained in:
John Cardinal
2020-03-11 22:37:25 +00:00
parent ef2dc569f1
commit b26571f185
1 changed files with 128 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

128
devdocs/specs/core-picklist-autocomplete-template-system.txt Normal file
View File

@@ -0,0 +1,128 @@
AUTOCOMPLETE PICKLIST TEMPLATE SYSTEM SPECS
PICKLISTS:
AUTOCOMPLETE
TODO FROM PLANS:
CLIENT UI
- WHERE USED
- Only used for *selection* on forms
- Not used in any main grids or in reports (unless people hit the PickList route in code behind the report)
- CONTROL:
- Use tagpicker as basis, already implements most of this
- Uses route at server that is dedicated to all picklists, accepts a type and search phrase returns results
- Must be a custom control even if it's just a wrapper around a regular autocomplete for future proofing
- Accepts a AyaType and handles all the rest automatically by knowing how to query the server?
- TEMPLATE templateable selects and display format for each major object type
- similar to datalistview editor but without filtering ability
- only one template per picklist type with option to default back to default
- Sane default with enough stuff to make it likely they won't bother to change it unless they need to
- SERVER
- route that accepts type and search phrase, returns results
- Uses template to determine which fields to query and include in return results
- Returns simple name / id pairs list easily bound to control
- Caches the templates and updates on change the cache
- AyaPickList is DataList equivalent
- Only need one object to contain default templates for all datalists since there is a finite amount
- make an sub area just like datalist for picklists to contain that stuff
- PickListView is the name of the template objects
- Similar to DataListView but static, one for each type of object only
- has default view if not overriden that is generally good enough for anyone
- PickList Controller ROUTES
- GetList(AyaType, query)
- Uses cached view (fetches into cache if not fetched to keep cache small)
- Use best practice caching for this so can extend to other things that need caching like BizRoles
- Based on cached view constructs a query with relevant columns only and containing search query in each column
- Also handles tags properly
- PutView(AyaType, viewJson)
- Update a view to use a new default
- updates cache when it updates db as well
- ResetView(AyaType)
- for ui, resets the view back to it's default
- GetView(AyaType)
- for ui picklistvieweditor to populate ui with current template (or default if not edited)
- GetViewList()
- for ui picklistview editor to switch lists
- autocomplete / search involves all displayed template columns
- support Search *IN* over all joined tables in list
- TAGS support
- Brainwave: include tags as an optional column they can include in template, so if it's far to the right won't intrude on view but can still search for tags right in the text you type!!
- this is a simple solution to tags issue
currently in v7:
- All picklists in v7 windows are autocomplete based on the START of the phrase typed only
- i.e. if you type in a Project box "pr" you will get "Project A", "Project B" but not a project called "ABC Project" as it doesn't search *in* the values
- This is simple and easy to intuit, maybe we don't need to get too far ahead of ourselves here.
- I do like the option of using tags in search and also a template that can be ordered like part display format for all this
IDEAS:
- AUTOCOMPLETE / SEARCH
- SEARCH *IN*
- Search in v7 was only start of string so search IN will be very helpful to people and a step up
- For example in v7 if a item was templated like Unit display format with manufacturer first, then search will start with manufacturer
so you couldn't search for the model number first or something, you had to start exactly at the start with the manufacturer
- DISPLAY TEMPLATE
- COMBINED WITH DATALISTVIEW or it's own thing?
- Potential differences between dlv and PickListView
- Only one default per object type, can't make many, so fixed collection of them
- No filtering combined with it
- Server has code that looks for datalist views generically to display a list of them or fetch them in a factory
- Client sends the template to the server to get the dlv, but a picklist is fixed though customizable for all users so client doesn't need to send it except when editing
- PLV need to be cached at server as they will be hit hard on nearly any form being opened
- Similarities between dlv and PickListView
- consumes a list of available fields pre-defined on a collection
- order and visible are settable by end user
- NAMING:
- "PickListView"
- In v7 display formats are used for the following:
- All picklists of that type
- In all main grid lists where that type is a JOINED display value not the main one:
- e.g. for UserNameDisplayFormat template: UserList just shows fields like name as they are, but Project list shows the project overseer (User) with the templated setting
- PROBLEM with v7 in filtering that combined column it actually only operated on the primary column name like "name"
- e.g. setting a filter on the workroderitempart list Part column of "eye" would not bring in part named "Thompson eyephones" becuase underlying it was searching only the part number field
- NOT IN GRIDS
- I think I can do away with the v7 feature of using the display format in joined tables of the main grids
- It didn't filter properly
- All JOINED table fields can be provided separately anyway for reporting and viewing and they would actually work with filtering
- NOT IN REPORTS
- Joined tables can be provided and combined in any way user wants on report so not a MUST have as it's fulfilled anyway
- Fixed, i.e. user can't insert their own characters in the display format but has a fixed method of separating fields
- Was thinking the DataListview stuff would be enough for picklist templates but actually there is very little real overlap here
- Maybe a kind of similar feature but focused on picklists instead?
- Selection templates for each object by TYPE?
- One central one, not unique to each user because..chaos.
- LINKED OBJECTS / TEMPLATES
- When you think about it there are few things that need to be linked for a template to display/search
- For example in v7 to make any display template for a Unit it needs Vendor name, Model name, Model number, Unit Serial number, Description
-that's 5 items of text info from at most 3 tables, it could just always query those three tables or fixup the query on the fly to minimize table joins
- So you could give the user the options of several text fields pre-defined, they set the order in the template and it searches and displays based on that
- TAGS
- How important are tags for initial release really?
- People want keyboard focused not a lot of clicking, so searching by tags is a bit of an issue:
- Maybe tags can be supported by a special typing sequence like enclose in special characters to search by tag like:
"{orange,red,yellow} Proj"
- OR, MAYBE have parallel selects beside (or above) each other, from left to right, top down or whatever, TAGS is first in row, then actual drop down of names
- if don't select a tag or clear it then only names are taken into account
- Most important first but they go as pairs in the same component
- TAG part displays very minimally at first unless it's been activated or selected (maybe an icon on the outside of the regular select which switches to tag mode?)
OLD RESEARCH AND NOTES
- This article is spot on and I need to implement it like this: http://jeremymikkola.com/posts/2019_03_19_rules_for_autocomplete.html
- Check article responses and comments here for tweaks: https://news.ycombinator.com/item?id=19438826