This commit is contained in:
@@ -41,147 +41,30 @@ CURRENT ROADMAP
|
||||
- Ability to upload v7 data from DataDump plugin
|
||||
|
||||
**************************************************************************************************************************************************************************
|
||||
COMPLETED:
|
||||
STAGE 1
|
||||
|
||||
CURRENT TODOs
|
||||
=-=-=-=-=-=-=
|
||||
|
||||
@@@@@@@@@@@ ROADMAP STAGE 1 and 2:
|
||||
@@@@@@@@@@@ ROADMAP STAGE 2:
|
||||
|
||||
|
||||
|
||||
todo: stuff below go-over and make sure nothing missed
|
||||
|
||||
todo: TEST Picklist on iPad, and shitty lenovo tablet
|
||||
todo: modify Widget form to use picklist to select user, test with huge tracts o'data
|
||||
todo: server generate data, can I just automate it like with the debug startup code so that I don't have to keep fucking around generating data on every server reboot?
|
||||
todo: on device testing of picklist (upload to server)
|
||||
todo: once get here go back to server project todo which is documentation I believe at this point
|
||||
- probably deserves it's own page as we want each topic small and focused, not a huge page of text in the user docs
|
||||
|
||||
|
||||
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 editor, 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
|
||||
- SEE SERVER SPEC DOC core-picklist-autocomplete-template-system.txt
|
||||
|
||||
- autocomplete / search involves all displayed template columns (including tags if present in template)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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
|
||||
todo: CLIENT PICKLIST DATALISTVIEW selector form
|
||||
- Will need under useroptions a central location to choose all datalistview for every type of picklist in AyaNova
|
||||
- User can leave at default or select a saved DataListView (or make one there) to use
|
||||
- Client will then pick up that format in any form where it's required
|
||||
|
||||
todo: MAKE PICKLIST COMPONENT Select lists and filtering by tag "select-search-filter-control"
|
||||
- Implement it as a component with built in searching and tag selection that is sticky by individual form item
|
||||
- this is an important crucial item and needs to be easy and clean
|
||||
- I'm thinking it auto searches by entry like RI, but you can open more UI and select tags to filter with it
|
||||
- Or maybe it's part of datafilter too?
|
||||
- See add food filter in diary in chronometer app for inspiration (though theirs is a bit dumb, you can only select one tag)
|
||||
|
||||
|
||||
|
||||
|
||||
=-=-=-=-=- AP - After Picklist =-=-=-=-=-=-=-
|
||||
|
||||
todo: TEST on iPad, and shitty lenovo tablet
|
||||
|
||||
todo: check picklist current default templates are adequate for now
|
||||
todo: picklist template editor UI at client end
|
||||
todo: document how to use picklist in user docs
|
||||
todo: login form on mobile (and desktop) is scrunched to the top, logo with almost no headroom, would like to see it all centered
|
||||
|
||||
todo: now that we have case insensitive should I port that shit over to the datagrid filter as well?
|
||||
|
||||
todo: Utilize new picklist in Widget form to select something that exists and can then test out DataListView etc
|
||||
|
||||
|
||||
todo: Should all icons be specified from a central location for future proofing and consistency?
|
||||
- Not sure after initial look at it if this is a good idea or not, think about again
|
||||
- consider the finished product and how many forms etc
|
||||
- What *is* a good idea is to remove the code that auto-prepends "fa-" to icons and enforce them as whole strings
|
||||
- This way can search for icons properly in code even if not centrally situation
|
||||
- right now I just specify they willy nilly and some with fa and some have functions that append fa
|
||||
- if I had a central object with keys that represent the concept of the icon then I can use that everywhere and it's an easy change all at once if something needs changing
|
||||
|
||||
|
||||
Reference in New Issue
Block a user