This commit is contained in:
@@ -23,15 +23,14 @@ Server
|
|||||||
- List of fields available for templates for client and server validation etc
|
- 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
|
- 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
|
- 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
|
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
|
- 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
|
||||||
TO BE DETERMINED
|
- This is because users will likely want that for many reports
|
||||||
- How will it actually work
|
- Kind of a calculated field
|
||||||
- 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
|
|
||||||
|
|||||||
Reference in New Issue
Block a user