52 lines
3.1 KiB
Plaintext
52 lines
3.1 KiB
Plaintext
DISPLAY FORMAT TEMPLATE SYSTEM SPECS
|
|
|
|
OVERVIEW
|
|
Narrow grids on small screens as well as picklists need to show a single field of information as required by that shop for selection, recognition etc so templated to format multiple return fields into one
|
|
|
|
Grids need a way to ensure you can see what you need on small devices as well they need to show the columns desired on larger devices
|
|
PickLists need a way to format what is returned for picking (with template)
|
|
|
|
Display format template (aka name display format) templates are used for THREE purposes:
|
|
- to customize what is shown in XS (<600px) single column grid and inside forms in drop down boxes order for a user to identify a record uniquely for selection purposes.
|
|
- To select which columns and in which order display on the grid in > 600px sizes
|
|
- To limit bandwidth used by selecting only the necessary columns
|
|
|
|
This is used for both small form factor grids (see core-main-grids.txt) i.e. on a phone as the only column displayed
|
|
This is also used for picklists inside forms like drop down boxes etc
|
|
|
|
CASES
|
|
none relevant
|
|
|
|
|
|
REQUIREMENTS
|
|
|
|
Client
|
|
- Main grid lists < 600px show only a single column based on template
|
|
- Selection drop down boxes in forms for selecting other objects
|
|
- Template editor under global settings for all main list objects
|
|
- Warning displayed to client if they select more than 16 columns to send out about bandwidth usage and slowness over slower connections
|
|
|
|
|
|
Server
|
|
- List of templates with their column selections
|
|
- For client editor
|
|
- For server to process what the query and send for lists
|
|
- List of fields available for templates for client and server validation etc
|
|
- Caching likely useful as server will need to deal with templates constantly as users fetch almost any list or combo box source etc
|
|
- Has to be very peformant as it will be doing this a lot
|
|
- SERVER handles composing the list object name display, NOT the client
|
|
- This saves bandwidth
|
|
- Incurrs more computing ops at the server but bandwidth is more expensive than server power all around
|
|
- Clients could be shitty and slow, this elminates that prospect
|
|
- Easier to code in c# than in javascript! ;)
|
|
- PICKLISTS and RIGHTS
|
|
- Initially I had picklist objects with just name and id and anyone could fetch them of any role, however, this isn't right and
|
|
- I'm leaving the rights up to the case by case basis and will address it when the client dev drives a requirement for it
|
|
- I'm thinking if people don't want a field exposed in mini list then don't put it into the template
|
|
|
|
Back AND front end
|
|
- Need to handle changes in fields gracefully i.e. a new field added in an update, a field removed in an update cleans out the template when detected etc
|
|
- Should send the customized templated display name field to the reports as well as all the regular including name fields
|
|
- This is because users will likely want that for many reports
|
|
- Kind of a calculated field
|
|
- Default templates come with Raven, user can customize further |