Aborted one-shot dialogs pollute the DOM

[jri]

When an one-shot dialog is aborted (by pressing the close box or the escape key) it stays in the DOM. The next time the dialog is opened it is appended again. Thus the DOM is polluted bit by bit.

One-shot dialogs are those which are appended to the DOM only when opened. These are expected to be removed from the DOM when closed (regardless of the close gesture used). One-shot dialogs comprise at least prompts. Its up the application weather a dialog is created as "one-shot" or "static".

These methods are concerned:

dm4c.ui.dialog()
dm4c.ui.prompt()

[Jörg Richter]

GUIToolkit fix: clear DOM on close dialog (#583).

Once a dialog is closed it is removed from DOM, regardless what close gesture is used.
The DOM is not polluted.

BREAKING CHANGES

Only "one-shot" dialogs are still suppurted. That means a plugin must add the dialog to the DOM only when it is supposed to appear on-screen.
In contrast, "static" dialogs are not supported aynmore (that was when a plugin adds the dialog to the DOM on init time and reuses it many times).

GUIToolkit Dialog API:

• open() is dropped. The dialog is now opened automatically on creation time.
• close() closes the dialog and removes it from the DOM.
• destroy() is dropped. Use close() instead.
• empty() is dropped.
• append() is dropped.

Webclient API:

• dm4c.do_delete_topic() takes a topic ID as argument (instead a topic).
• dm4c.do_delete_association() takes a topic ID as argument (instead an association).
• dm4c.do_retype_topic() takes a topic ID as argument (instead a topic).

See #583.

• Changeset: b3d913fb0b2c20d37d2363561aff7971f3ceb043
• URL: ​https://github.com/jri/deepamehta/commit/b3d913fb0b2c20d37d2363561aff7971f3ceb043

[Jörg Richter]

Webclient GUITookit: revise dialog closing (#610).

GUIToolkit's Dialog handling is simplified.

In standard cases the caller of dm4c.ui.dialog() ...

1. must no longer care about closing the dialog. The dialog is closed automatically, provided it has a button (and thus a button handler). If it has no button, it's still up to the caller to care about closing. If the caller supplies a button handler but want handle closing itself she can use the new auto_close config setting:

   dm4c.ui.dialog({
       ...
       auto_close: false
   })
   

auto_close controls if the button closes the dialog (boolean). Default is true. If false is specified the caller is responsible for closing the dialog. The auto_close value has only a meaning when a button is supplied as well.

As a consequence in standard cases the caller is not required anymore to store the Dialog object in a temporary variable.

2. must no longer care about binding a Return key listener to any dialog input element. The dialog invokes the button handler automatically when Return is pressed inside the dialog, provided the dialog has a button (and thus a button handler). If no button handler is supplied the caller still must bind a key listener itself (in case Return key behavior is demanded). If a button handler is supplied, but the caller want prevent its invocation on Return, she must bind a key listener and stop propagation (be returning false).

CHANGES

Webclient API:

Callers of dm4c.on_return_key() can stop event propagation by returning false from the callback function passed.

BREAKING CHANGES

GUIToolkit API:

2nd argument of dialog.close(), the callback, is dropped.

For other recent breaking changes related to the Dialog API see #583.

See #610.

• Changeset: 4d93fde972130c33e5cbe261fed44393c45c9744
• URL: ​https://github.com/jri/deepamehta/commit/4d93fde972130c33e5cbe261fed44393c45c9744