Alignment instructions

Please follow them in the given order.

• Files and folders structure
• New references and adapterModule
• Changes around CRUD methods (Create, Read etc)
• Changes on Adapter Actions (Push, Pull etc)
  • If you override the Push:
  • If you override the Pull:
  • If you override the former "Delete"
  • If you override the Execute:
• Dependency Types and Comparer
• TEST!!

Files and folders structure

Most of the Toolkits already follow these conventions, but better be safe:

1. No Push/Pull/etc. override in the [SoftwareName]Adapter.cs file. You must have one file per action override (Push.cs, Pull.cs, etc; no Push or Pull in the same file). File must be named like the action being overridden.
2. All files containing Action overrides must sit in a Folder called "AdapterActions" located at the root of the Adapter project. Follow this folder structure.
3. CRUD methods must sit in a folder called CRUD, located at the root of the Adapter project. Just create a root CRUD folder and move all your CRUD files in there. If you had an existing folder structure (e.g. Create/Create.cs) keep the folders as sub-folders of the root CRUD folder.
4. If you have non-CRUD related methods in the CRUD folder, move them out of there as appropriate.

New references and adapterModule

1. In your Adapter project, add a reference to BH.Adapter.oM and BH.Adapter.Engine (see BH.Adapter.oM and BH.Adapter.Engine).

   Make sure Copy Local is set to false.

2. Only for Structural Analysis adapters (e.g. Robot, Tekla, etc.)

   • Add a reference to Structure_AdapterModule into your adapter project.
   • Add the line

     BH.Adapter.Modules.Structure.ModuleLoader.LoadModules(this);
     

     in the constructor of your Adapter. See example for GSA here.

Changes around CRUD methods (Create, Read, etc.)

1. Create and Read are now virtual. If you had to implement them just because they were abstract, so you've left them empty, now you must delete them. If this means that your CRUD folder remains empty, delete also the folder.

2. All base CRUD methods were renamed with an I in front (e.g. Create -> ICreate, Read --> IRead, etc.).

   Rename them to match the signature with the new one. Example for the Create.

3. UpdateProperty has been renamed to IUpdateTags and its logic reduced to update tags only.

   If you were implementing it, follow the example on GSA_Toolkit.

4. AdapterId has been renamed to AdapterIdName.

   • Rename the Adapter property AdapterId to AdapterIdName.
   • If you have AdapterId in your Engine.Convert, please rename also that one to AdapterIdName for consistency. See example for GSA.

5. Another change is needed on the input Dictionary<string, object> config of all CRUD methods; it's covered in points 2b/2c below.

Changes on Adapter Actions (Push, Pull etc)

If you override the Push:

1. Change its signature in order to match the new one

2. Dictionary<string, object> config input has been replaced by the class ActionConfig.

   2a. Add using BH.oM.Adapter; in all Adapter Action files (Push.cs, Pull.cs, etc)

   2b. In all Adapter Actions and in all CRUD method signatures, replace Dictionary<string, object> config with ActionConfig actionConfig. If you didn't have an oM project for your Toolkit, create it for this.

   If you were NOT making use of the config dictionary, it's enough for the config, so go to point 3. Otherwise:

   2c. If you were making use of the config dictionary, create a specific type of ActionConfig for your toolkit. Follow the example for Mongo here. It must be called [SoftwareName]Config, inherit from ActionConfig and sit in your Toolkit oM project under the namespace BH.oM.Adapter.SoftwareName. Whatever Dictionary value you were storing in config must become a property of your new ActionConfig.

   2d. Implement the required logic in any method that needed to read values from the old config Dictionary. Follow the example for Mongo here. Essentially it's just a cast to your specific type of ActionConfig.

3. Add in these lines at the top of your Push override, before anything else.

   If at the end of your override you return the base Push, go to "If you override the Pull". Otherwise, check point 4:

4. If you do not return the base Push in your override, and if you make use of BHoMObjects in your Push, add in these lines at the top of your Push override, just after the lines added at point 3.

   Make sure you use objectsToPush for the rest of your override.

   If your Push is meant to for objects different from IBHoMObjects (like IObjects, or other non-BHoM types) you can skip this step.

If you override the Pull:

1. Change its signature to match the new one
2. For AdapterConfig, see point 2 of "If you override the Push".

If you override the former "Delete"

1. Adapter Action Delete is now renamed Remove. Rename it.
2. Change its signature to match the new one
3. For AdapterConfig, see point 2 of "If you override the Push".
4. Make sure also the Filename is renamed to "Remove".

If you override the Execute:

1. Change its signature to match the new one
2. For AdapterConfig, see point 2 of "If you override the Push".

Dependency Types and Comparer

Applies only if you have / make use of DependencyTypes() and Comparer().

1. DependencyTypes() (the method) is renamed to GetDependencyTypes(), and does not need to be implemented in the Toolkit anymore; instead, populate the new property Dictionary DependencyTypes.

   You just need to use the content of DependencyTypes() method to populate the DependencyTypes property in your Adapter constructor (which some adapters already have). Follow the example here.

   Once this is done, delete the DependencyTypes() method from your toolkit.

2. Similarly to point 1., the method Comparer() does not exist anymore; instead, take its content and populate the property AdapterComparers in your Adapter constructor. Follow the example here.

   Delete the Comparer() method when done.

3. For structural adapters only

   We now want to make sure that exporting Loads and their target element (Bar, Mesh, Point) can be done in the same Push (i.e. without having to Push the bars, Pull them back with their ID assigned, apply the Load to these latter ones and Push the load).

   In order to obtain this, the dependency Types must include the dependency between Load and the relevant Structural Element (e.g. Node, Bar). Follow the example from GSA here.

Test

Please state how you tested the refactoring and attach any test file suitable for the scope in the PR. The test file should be easy enough to be followed by anyone not familiar with the Toolkit, otherwise please add some short instructions.