From 0fb645858b21d3d723425a56e72b3815b00c233c Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Tue, 3 Dec 2019 18:35:34 +0000 Subject: [PATCH] --- devdocs/specs/core-customize-form-fields.txt | 9 ++++----- devdocs/specs/core-localization.txt | 17 +++++++---------- 2 files changed, 11 insertions(+), 15 deletions(-) diff --git a/devdocs/specs/core-customize-form-fields.txt b/devdocs/specs/core-customize-form-fields.txt index 3574d2c6..f9673821 100644 --- a/devdocs/specs/core-customize-form-fields.txt +++ b/devdocs/specs/core-customize-form-fields.txt @@ -17,8 +17,8 @@ UI FEATURE - The ability to customize forms: - When customize is selected a generic form pops up with a list of fields provided by the backend and their current settings and controls - This form can then be re-used everywhere as it's a stock object and this way we don't need to have a customize form for every existing CRUD form - Choosing to expose one or more of up to 16 custom fields on form in custom field section that shows when at least one is enabled - - Set the localized text for the current locale for every existing field and any custom ones enabled - - Show in the UI that a particular field is shared so that users know they are changing system wide i.e. "CommonActive" or "Tags" + - NO ability to edit localized text here, that's a separate central UI thing. + - Yes, v7 allows editing of lt in a form but I've decided to focus on one thing for this and not confuse it - Set whether a field is visible or not to user - Some stock fields will never be able to be hidden, they will be "core" fields required for AyaNova operations and will have their hidden checkbox grayed out - Set whether a field custom or stock is required to have a value entered or have it's value changed @@ -33,8 +33,7 @@ UI FEATURE - The ability to customize forms: - SERVER HANDLING - Custom fields are stored *with* their associated record in a single TEXT column as a serialized JSON object - {c1:"blah",c2:"blah",c3:"blah".....c16:"blah"} - - According to the docs https://www.postgresql.org/docs/9.1/datatype-character.html this is pretty efficient - - I don't like the idea of an outside table holding all custom values, it would be hammered pretty hard, this way the data stays with it's record + - According to the docs https://www.postgresql.org/docs/9.1/datatype-character.html this is pretty efficient - The server doesn't validate it or anything, just stores what the client provides and retrieves what the client needs and the client co-erces the value to the correct type - If a user changes the underlying objects type then the client must handle discrepencies and attempt to fix it. - So the client end must handle adapting the value if the type changes @@ -84,7 +83,7 @@ UI FEATURE - The ability to customize forms: - #DONE# TESTS for the above!!! - - Put custom fields into widget object or figure out how we will handle that aspect + - #DONEPut custom fields into widget object or figure out how we will handle that aspect EXISTING v7: diff --git a/devdocs/specs/core-localization.txt b/devdocs/specs/core-localization.txt index 28188638..1bdad071 100644 --- a/devdocs/specs/core-localization.txt +++ b/devdocs/specs/core-localization.txt @@ -2,7 +2,13 @@ REQUIREMENTS - - Client does *ALL* localization locally, only exception is the server ops logs + - CENTRAL LOCALE EDIT FORM + - End user customizes localizations from a central location with a kick ass search and change ability + - We will *not* support localization changes form by form as in v7 but only from central location + - Faster to code TTM + - User doesn't think they are only changing it on one form only + - Some forms don't have all the related keys on them (i.e. a list will show "Widgets" even though the edit form never shows that string) + - Client handles *ALL* localization presentation locally, only exception is the server ops logs - This saves bandwidth and hassle and leaves presentation to the client where it belongs (was a source of trouble in v7) - Keys are text, human readable and as short as possible - Not numeric ID's for these, strictly textual @@ -70,9 +76,6 @@ Note: still some dupes but...fuck it -- TODO: As I code, I will select lt keys as required enter them below - - - TODO: Some of the keys are new and not translated from English, when all is done and the keys that will be carried forward are determined, check for untranslated ones - Use Google translate to get a rough approximation. @@ -95,11 +98,5 @@ CHANGES: - If the text is changed at the server then a notification should occur for clients using that local to invalidate their cache - Although, that would be a pretty rare event so...maybe not so much, a logout could clear the cache or a login I guess -*********************************************************************************************************************************** - -LOCALIZED TEXT KEYS ACTUALLY USED -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -This is actually irrelevant now because I'm coding the client to only fetch the exact keys it needs for each form, -so there could be thousands of unused keys and it wouldn't matter.