Question

What exactly does a blocking pop-up block?

4

This relates to the earlier still unanswered question here: Returning a selection from a modal select pop-up . I have tried to use the technique of creating a temporary record in a Popup _ Result table (associated with the Incident) to store the new Status selected, or to identify the Incident to update. I tried to use microflows shown here to store the selected value in the popup_result record, but the Blocking Popup (the Select list of statuses) does not stop the microflow and the workflow marked as 'A' carries on before the user has made their selection. Is this correct behavior? I would have expected a blocking popup to stop all processing until the dialog has been closed. To get around this, I removed the workflow after 'A' and instead changed the worklow marked 'B' to update the Incident directly at this point (and delete the popup _ result record). This works, but the problem occurs if the user does not make a selection and uses the window 'X' control to close the popup dialog. This leaves an orphan Popup_Result record associated with the current Incident. If they then go to change the Status of a different Incident, this orphan record may cause the wrong Incident to be updated. Is there a way to suspend a microflow after opening a popup form until the form has been completed and closed? Or, what is the best way to stop a user exiting a popup using the Windows 'X' or Alt-F4 to force the microflow on the popup to be executed?

asked 2010-06-02

David Sanders

2 answers

1

I think I have overcome the problem of a potential orphan record linked to the wrong Incident by making the first action a retrieve for any existing record for that user, and if found, updating the association to link to the current Incident

answered 2010-06-03

David Sanders

Michel Weststrate · Accepted Answer · 2010-06-02

Hi David,

You need to define indeed two different microflows, blocking only indicates that the user cannot (simply) navigate to another form. Off course, you cannot stop the user from exiting a window with ALT-F4 or X, that would be a serious security and privacy thread (imagine what would happen if an ad makes use of such features). So in order to prevent orphans, you could simply run a scheduled microflow every night which delete all orphan objects.

To make a popup 'blocking' in a microflow, you could create a java action which blocks (Thread.sleep(millis)) until a certain condition is reach. In which case the condition is the creation of a certain object, done by another microflow triggered by a button in the form. However this does not really simplify the problem. And i suggest indeed using 2 microflows.

[BACKGROUND] Generally speaking, i think you should look at user interaction from another paradigm, when building forms, every action (microflow in the case of mendix) should be triggered by an event (the user clicks a button). This in contrast to the classic console model where the applications 'hangs' until the user has entered the next input. Although the latter is more simply to implement and reason about, its pretty limited, and has nasty side effects such as the fact that the server needs to keep track of an extra active thread (microflow) per user which is logged in to the system! So in short, you should see a microflow of a transitions which brings the user in a next state where he can undertake one or more actions. But the handling of that chosen action is a whole new transition and therefor a separate microflow. [/BACKGROUND]