From eae63bbe56982c130f7e253ffdb415f1fc75ea2c Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Thu, 9 Jan 2020 18:31:54 +0000 Subject: [PATCH] --- .../core-display-format-template-system.txt | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/devdocs/specs/core-display-format-template-system.txt b/devdocs/specs/core-display-format-template-system.txt index 5686ed81..ee78a11d 100644 --- a/devdocs/specs/core-display-format-template-system.txt +++ b/devdocs/specs/core-display-format-template-system.txt @@ -23,15 +23,14 @@ Server - 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! ;) 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 - -TO BE DETERMINED - - How will it actually work - - Does the client or the server compose the field based on template? - - Bandwidth considerations - - Server load considerations - - Server latency considerations - - Client power churning through a big list considerations - - DB objects and server objects and routes + - 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