Provide a strategy for host integrator's to set the python template at startup

[alfarok]

Purpose

DYN-1507

This PR provides a strategy for a Dynamo host integrator to programmatically set the path of the Python nodes default template at startup. This is accomplished by setting the PythonTemplatePath on the configuration file that will be passed as a parameter to the DynamoModel when instantiated. It is required that the host integrator uses either the DefaultStartConfiguration struct or creates a struct that inherits from DefaultStartConfiguration. For example...

var config = new DynamoModel.DefaultStartConfiguration()
            {
                PythonTemplatePath = "C:\\Users\\alfarok\\Desktop\\PythonTemplate.py"
            };

var model = DynamoModel.Start(config);

Users are still able to override this file if desired by modifying the <PythonTemplateFilePath> attribute in the DynamoSettings.xml file or adding a a new template file in the appropriate AppData location (see below). To fallback to either host integrator path or the hard-coded template provided in Dynamo Core simply remove the path from the settings xml or delete the template file from the AppData location. Lastly, if a invalid path is provided the default Core template will be applied.

Logging

(In sequential order)

Loaded from DynamoSettings.xml

Loaded from Host Integrator

Loaded from AppData

Loaded Default Template

Overriding the default or a host integrator template as a USER

Users looking to override the template can do so in the following ways introduced in #8122:

Option 1 - Default AppData Location

Add a new python file named PythonTemplate.py to the C:\Users\alfarok\AppData\Roaming\Dynamo\Dynamo Core\2.2 directory

Option 2 - Custom Location using DynamoSettings.xml

Add a custom path to the DynamoSetting.xml under the PythonTemplateFilePath tag such as
<PythonTemplateFilePath>C:\Users\alfarok\Desktop\PythonTemplate.py</PythonTemplateFilePath>
(Does NOT require PythonTemplate.py naming)

Testing

Unit tests have been added to verify API usage for valid and invalid template paths. Additionally, this has been manually tested by modifying the DynamoSandbox startup config to include a PythonTemplatePath which is set here and invoked here. Testing coverage for loading the default template as well as a user template already has coverage.

Declarations

Check these if you believe they are true

• The code base is in a better state after this PR
• Is documented according to the standards
• The level of testing this PR includes is appropriate
• User facing strings, if any, are extracted into *.resx files
• All tests pass using the self-service CI.
• Snapshot of UI changes, if any.
• Changes to the API follow Semantic Versioning, and are documented in the API Changes document.

Reviewers

@QilongTang @mjkkirschner

[alfarok]

This is done because the DynamoModel constructor takes a IStartConfiguration config as its only param. I believe modifying the interface (even adding a new property) would be an API breaking change, but feel free to correct me if I am wrong on this or there is a better strategy.

[mjkkirschner]

I think you should do something like:
defaultConfig = config as DefaultStartConfiguration and then check for null because it's possible that the concreteType is NOT a DefaultStartConfiguration ... and that needs to be handled. (ie missing the python template field you just added)

[mjkkirschner]

alternatively you can add a second interface and check if the object implements that interface, if it does - do the right thing and set the path.

[QilongTang]

👍 Same options in https://jira.autodesk.com/browse/DYN-1644

[mjkkirschner]

in general, I don't think casting like this is a great idea for the problem we are discussing as casting can throw - as and is should not.

https://docs.microsoft.com/en-us/dotnet/api/system.invalidcastexception?view=netframework-4.7.2

[alfarok]

Thanks for the feedback guys. I was not happy with this approach either but as cannot be used with a non-nullable value type which DefaultStartConfiguration is as a struct. This is why I wrapped this logic in a try/catch returning the default template if an exception is thrown. However, performing a check such as

if(config is DefaultStartConfiguration)
{
    // Proceed in checking if a custom template path is available and valid
}
else
{
    // Use default template
}

is possible but does not guaranteed the PythonTemplatePath has been set. Attempting to retrieve the PythonTemplatePath property will simply return null if it was not set and I verify this is not the case below before proceeding. Long story short we can probably use is to verify the config is of the DefaultStartConfiguration type or of a type that inherits from it. I don't think adding another struct is necessary just for this property. If the config is of another type we return the default template. I believe the try/catch can also be removed with is as @mjkkirschner suggested since it will not throw. What do you guys think about this approach? @QilongTang

[QilongTang]

Sounds good to me.

[QilongTang]

@alfarok Once you wrap this up, please also attach the screen shot of console with this change so clients know what to expect from console. Thanks

[alfarok]

@QilongTang I just added one new logging statement for when a custom template is loaded via the config, however it turns out none of the old statements ever successfully logged to the console or log file. Possibly because the DynamoModel is still being instantiated? I need to debug more but at first glad I don't see any exceptions thrown stepping through the logger

[QilongTang]

@alfarok Sure, could be related to the sequence of how preference setting and logger are initialized

[alfarok]

@QilongTang Added screenshots for all the logging statements. There were a couple issues with the previous logging logic which took me a little while to uncover. It appeared the logging wasn't working because the localized strings were embedded only in the Resources.resx file but should have also be in the Resources.en-US.resx, so logging was working but printing empty strings. I believe I enumerated all the scenarios and verified the correct statements align with the correct logic. Will get an some unit tests added and this should be good to go.

[alfarok]

Added unit tests verifying API usage for valid and invalid template paths. I think this should be ready to go

[QilongTang]

Look perfect on my side!