We can introduce a new feature justified by the increasing usage of downstream implementations of the BHoM Adapter from non-UI contexts – i.e. adapter code called from some other code (e.g. Excel_Adapter's Push being called from other Toolkits).
In these contexts, specific Actions (e.g. the Push) can happen to need some "preparation" and "teardown" activity. These activities typically need to be performed once per Action, but they need to be called programmatically when the Action is invoked programmatically.
For example, the Push from Excel. If called from the context of an UI, the Push will create a workbook, then write to it, then save the workbook. If the Push is called from another piece of code, however, you may have several lists of objects (a list of lists input) that you want to push. In this case, you are forced to call the push for each input list, which incurs in unneeded overhead for the workbook and saving creation per each list, which slows things down. Some workaround that essentially create objects to group have been attempted, but we may solve this by introducing optional overridable methods (see https://github.com/BHoM/Excel_Toolkit/pull/54 and its "grouping" object).
We can introduce the following virtual methods that are by default empty:
BeforePush/AfterPush
BeforePull/AfterPull
... etc. (same fore every action)
Each of these methods will have to take as inputs all of the inputs available to the main action. These methods can then be implemented as required by downstream toolkits. This addition won't affect existing downstream implementations.
Description:
We can introduce a new feature justified by the increasing usage of downstream implementations of the BHoM Adapter from non-UI contexts – i.e. adapter code called from some other code (e.g. Excel_Adapter's Push being called from other Toolkits).
In these contexts, specific Actions (e.g. the Push) can happen to need some "preparation" and "teardown" activity. These activities typically need to be performed once per Action, but they need to be called programmatically when the Action is invoked programmatically.
For example, the Push from Excel. If called from the context of an UI, the Push will create a workbook, then write to it, then save the workbook. If the Push is called from another piece of code, however, you may have several lists of objects (a list of lists input) that you want to push. In this case, you are forced to call the push for each input list, which incurs in unneeded overhead for the workbook and saving creation per each list, which slows things down. Some workaround that essentially create objects to group have been attempted, but we may solve this by introducing optional overridable methods (see https://github.com/BHoM/Excel_Toolkit/pull/54 and its "grouping" object).
We can introduce the following
virtualmethods that are by default empty:BeforePush/AfterPushBeforePull/AfterPullEach of these methods will have to take as inputs all of the inputs available to the main action. These methods can then be implemented as required by downstream toolkits. This addition won't affect existing downstream implementations.
These methods should be by default invoked by BHoM_UI just before and just after the Action method, that is, respectively at the last and at the first useful moment. This means e.g.
BeforePush()should happen after anySetupPushType()andSetupPushConfig(), andAfterPush()should be called just after the call to the Push. See https://github.com/BHoM/BHoM_UI/blob/ae56ad7a7d2650bf99197e0ba864fb3abfc6be55/BHoM_UI/Components/Adapter/Push.cs#L89-L115