This topic contains 3 replies, has 0 voices, and was last updated by dc92974 6 years, 7 months ago.
-
AuthorPosts
-
April 2, 2018 at 12:43 pm #18073
dc92974We have a suitescript file that has common internal ids we reference in our code. Class ids, Ship method ids, etc. Anyone have a suggestion how we can use 1 file for 1.0 and 2.0 scripts?
I was thinking a JSON config file that way 1.0 and 2.0 scripts could read it. Ran into a problem that client scripts can’t read files from the document library though.
This is a cached copy. Click here to see the original post. -
April 4, 2018 at 8:33 am #18074
MChammaTXFor client scripts, you could push the data into a hidden field in beforeLoad and then parse it in your client script. Alternatively you could use a custom record for your config.
-
April 4, 2018 at 9:08 am #18075
khultquistI like the idea of custom record, that’s the cleanest, plus it’s available for your future scripts.
-
April 4, 2018 at 10:47 am #18076
dc92974Thanks for the suggestions, did some prototyping and we’re going with the custom record. Created basically a key/value pair record to store the config data. Then we created 1.0 and 2.0 โloadersโ that retrieve the data and convert it to a javascript object that replicates our existing structure (from a javascript library file). The 1.0 version loads the entire record once per script, the 2.0 version also includes caching the data (still playing with this).
We also created a simple backup process that archives the record data to the file cabinet and keeps x days worth of backups. Not exactly source control but does provide a little bit of a security blanket.
Winsโฆ
Config is moved to custom record
“1.0” scripts do not have to be retrofitted
“2.0” scripts can include caching
“2.0” scripts can load subsets of the config if they need to
Having 1 file was problematic managing production and sandbox values. The custom record fixes this because the data is stored within each environment
-
AuthorPosts
You must be logged in to reply to this topic.