Closed Ducasse closed 10 months ago
Yes, many users of IceTipStandardAction
have this problem. Chasing it down for a bit, it seems many of them have been migrated to a new pattern where the calling IceTipCommand
asks for a #newWhateverAction
then sends it executeWithContext:
, rather than calling a method which makes and immediately evaluates the IceTipStandardAction
. See for instance IceTipDeleteBranchCommand>>execute
, making use of IceTipBranchModel>>newDeleteAction
.
I believe I've managed to chase down all the remaining cases—PR incoming.
I was thinking to first add
application
^ StPharoApplication current
in the superclass of action. Then later we can pass an application.
I thought of something like that, but by the time I determined what the right default value for application
would even be (StPharoApplication current
sounds right, yes), I had discovered that the vast majority of commands were already using the #newXAction
+ #executeWithContext:
pattern. And all the cases I found were easily migrated to that pattern, so no need for a hard-coded default.
Ah then even better. Now since we want to remove the dependencies to UIManager the "UI" should be passed via the Application. This way we will one single point of control.
The problem is that it is unclear how to reach the current application.