Make screen action an input parameter type

On our radar
When a web block has multiple elements which normally trigger a screen action, externally assigning a different screen action to these elements can be don't in a nice way.

The elements themselves should trigger a notify event with a message which indicates the element which was triggered. Then it is up to the consumer to create a screen action in which the message is used to determine which action flow to follow.

As an example, say a web block was created in which there is a save and cancel button. The consumer of this web block creates a screen action in which handles the notify event. Within the screen action an if statement is placed to check if the message of the notify event was save or cancel. Then the true or false flow will actually handle both flows within the same screen action.

It is my opinion that it would be nicer to have input parameters of the type screen action in which you can assign a reference to an external screen action. That way the consumer can create screen actions for a specific purpose which get triggered within the web block.

Following the example above, it would mean that the web block gets 2 input parameters of the type screen action; SaveAction and CancelAction. The consumer defines 2 screen actions; SaveScreenAction and CancelScreenAction and assigns them to the matching parameters. Then the save and cancel buttons within the web block can trigger these screen actions.

The advantage of this is that it becomes possible to create more generic web blocks which act more like native controls where it is possible to reference a screen action like a button control.
Created on 17 Nov 2015
Comments (4)
18 Nov 2015
You mean call-backs. I'm not sure whether I would be in favour of that, apart from the fact that technically it's not trivial, as in the context of the web block, those actions (and their context) do not exist.
19 Nov 2015
The alternative is to have more custom events instead of just one notification event. In that way it is also possible to bind to a specific event without the need to analyse a string value just to see what happened.

The current way of working requires insight into the web block one is consuming, which is something you don't want to bother other developers with. in my opinion a web block should be self contained and clearly understandable without the need to dive into it so determine how it can be used.
19 Nov 2015
isn't that the job of the develope of the webblock itself?

19 Nov 2015
Well, that depends on the type of web block you have. If you always have a Save and a Cancel button, you may put them in a web block (being standard UI elements etc.). But to handle them, it would be nice if you could, from the web block, trigger Screen Actions in the consuming screen. Currently you're stuck with a single OnNotify.