Added "Setup" methods to do the Actions input setup that was in BHoM_UI

[alelom]

NOTE: Depends on

BHoM/BHoM_UI#329

Issues addressed by this PR

Closes #259

Moves the logic related to the Adapter Actions setup from the BHoM_UI in the Adapter.
Advantages:

• Flexibility: Toolkits can now override the new SetupThen[ActionName] methods if they need to have different set-up.
• Consistency: logic related to the adapter is all in one place. See Move all logic inside Adapter Action UI components to the Adapter #259 for more info.
• Does not require any alignment: all Toolkits will work as before.

I need this quite urgently now because of some needed changes in other toolkits (File_Adapter).

Test files

Changelog

Additional comments

[adecler]

Most of the code in here is aimed at handling null cases. So wondering if it wouldn't make more sense to have that directly into to core method instead of a separate one. Genuine question though as I haven't been involved with the adapters long enough that my question might have an obvious answer.

[alelom]

Most of the code in here is aimed at handling null cases. So wondering if it wouldn't make more sense to have that directly into to core method instead of a separate one. Genuine question though as I haven't been involved with the adapters long enough that my question might have an obvious answer.

The main point of having the logic here is to allow overriding by Toolkits. This gives the flexibility of adding checking/verification/additional settings to the "SetUp" methods, or replacing entirely what we do at the base. This is useful in several scenarios.

[IsakNaslundBh]

Like the action config and request stuff, but think the adapter checking for Move as well as the object checking for push is one step to many. Those to me are clear parts of the push, not something that is simply cleaned up a bit before.

[IsakNaslundBh]

Most of the code in here is aimed at handling null cases. So wondering if it wouldn't make more sense to have that directly into to core method instead of a separate one. Genuine question though as I haven't been involved with the adapters long enough that my question might have an obvious answer.

To expand a bit on alessios answer, it is more about defaults and converts than null checks, and making it possible for each adapter to handle that differently. For example, being able to convert a string, formatted in a specific way into a request that is friendly to that particular adapter, but non-sensical outside that scope.

As for the ActionConfigs, could be used by RevitToolkit for example, that make use of that mechanism a lot, to directly instantiate the appropriate ActionConfig required by a particular action, such as Pull.

[IsakNaslundBh]

some small additional tweaks

[IsakNaslundBh]

now LGTM. Think this is a good balance!

[alelom]

/azp run BHoM_Adapter.CheckInstaller

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).