For easier viewing of this PR since a lot of these changes are making the formatting consistent please use this link to ignore whitespace changes.
There currently is a ST deploy scheduled for Tuesday afternoon (Jan 3rd) that adds a few new API methods that will put CoRE the Class File limit again. ST has already refactored quite a few APIs on our end to try and get CoRE back under the limit, but weren't able to quite get close enough. In looking at CoRE there seemed to a be a few places where pulling some logic out of CoRE and into a ST utility would be an easy win for both of our problems. The first things we noticed was the colors() List of Maps. This Map has now been moved into a ColorUtilities class in ST which can be accessed from any SA/DTH using colorUtil. Therefore, colorUtil.ALL is now roughly the equivalent of what colors() was before except we took Random out as the first element and we just inject that before displaying it in CoRE instead.
Syntax will look like the following after the scheduled release will go out to give you an idea how it can be accessed and what methods would be available:
colorUtil.findByName('White') // case insensitive
colorUtil.ALL*.name
colorUtil.BLUE
colorUtil.RANDOM // returns a random color from colorUtil.ALL
Here is a screenshot of what colorOptions() inputs now look like with these changes and pulling from colorUtil instead, notice we used the same exact sort order with Random and the various white color options at the top.
Most likely existing users with older installs shouldn't run into any issues, but any newer installs that run into Class file too large! errors after the deploy will definitely need to upgrade.
The only downside here is that any changes to existing colors (rgb, etc...) would require an ST change and deploy or go back to using the colors map if Class file size allows. However, new colors could be added allColors() and then alpha sorted until a new ST deploy happens where they would become available. I don't think this is a huge concern since I don't think they change all that often.
For easier viewing of this PR since a lot of these changes are making the formatting consistent please use this link to ignore whitespace changes.
There currently is a ST deploy scheduled for Tuesday afternoon (Jan 3rd) that adds a few new API methods that will put CoRE the Class File limit again. ST has already refactored quite a few APIs on our end to try and get CoRE back under the limit, but weren't able to quite get close enough. In looking at CoRE there seemed to a be a few places where pulling some logic out of CoRE and into a ST utility would be an easy win for both of our problems. The first things we noticed was the
colors()List of Maps. This Map has now been moved into a ColorUtilities class in ST which can be accessed from any SA/DTH usingcolorUtil. Therefore,colorUtil.ALLis now roughly the equivalent of whatcolors()was before except we took Random out as the first element and we just inject that before displaying it in CoRE instead.Syntax will look like the following after the scheduled release will go out to give you an idea how it can be accessed and what methods would be available:
Here is a screenshot of what
colorOptions()inputs now look like with these changes and pulling fromcolorUtilinstead, notice we used the same exact sort order with Random and the various white color options at the top.Most likely existing users with older installs shouldn't run into any issues, but any newer installs that run into
Class file too large!errors after the deploy will definitely need to upgrade.The only downside here is that any changes to existing colors (rgb, etc...) would require an ST change and deploy or go back to using the colors map if Class file size allows. However, new colors could be added allColors() and then alpha sorted until a new ST deploy happens where they would become available. I don't think this is a huge concern since I don't think they change all that often.
/cc @ady624 @vl4ds