Dialog's and relevance

All,

After thinking a lot about how relevance and a dialog need to work together, I came to the conclusion that it is probably best to let it work as close as possible to how a case in a switch works together with relevance. This has some consequences on what events are or aren't dispatched, I will elaborate the possible situations and the events that will occur. If you think something should behave differently please let me know.

* Bound node is relevant and show action is invoked, dialog isn't open

1.       Adjust the visibility state of the dialog

2.       Enable the XForms action handlers that are listening for events

3.       Dispatch an xforms-enabled to the dialog

4.       Dispatch an xforms-dialog-open to the dialog

* Bound node is relevant and show action is invoked, dialog is already open

1.       The action just no-ops

* Bound node is non-relevant and show action is invoked

1.       The action just no-ops

* Bound node becomes non-relevant, dialog isn't open

1.       Nothing happens because the dialog is already considered non-relevant because its state is closed

* Bound node becomes non-relevant, dialog is open

1.       xforms-disabled event arrives on the dialog

2.       Adjust the visibility state of the dialog

      Note: Dialog closes but no xforms-dialog-close is dispatched

* Dialog is open and hide action is invoked

1.       Dispatch an xforms-dialog-close to the dialog

2.       Dispatch an xforms-disabled to the dialog

3.       Disable the XForms action handlers that are listening for events

4.       Adjust the visibility state of the dialog


The two main differences compared to how I thought it will work are:

1.       The show and hide actions do the magic of showing/hiding the dialog, it isn't the default action of the events (xforms-dialog-open and xforms-dialog-close). This has the main disadvantage that you can't prevent the dialog to open/close by canceling the xforms-dialog-open/xforms-dialog-close event and you can't open or close a dialog by sending the appropriate event. But this would be hard to implement/specify, because we would define a closed dialog as being non-relevant and you can't send events to non-relevant 'controls'. And you can always send an event to open or hide action which solves the second problem.

2.       You don't always get an xforms-dialog-close event when a dialog closes. The event won't be send when the dialog is closed due to the bound node becoming non-relevant of an open dialog. But you do get the xforms-disabled event, I think we should extend the context info of the xforms-disabled event so you know if it was sent due to an SNB becoming non-relevant, a dialog being closed or a case being deselected.

For each difference there is a good reason why we decided to do it like this, and moreover it is in sync of how switch works today.


Regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office Fax: +32 3 821 01 71
Nick_Van_den_Bleeken@inventivegroup.com<mailto:Nick_Van_den_Bleeken@inventivegroup.com>
http://www.inventivegroup.com<www.inventivegroup.com>


________________________________
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--