The purpose of confirmation dialogs is to prevent misclicks and to inform the user of potential consequences of their action.
+A confirmation dialog should always ask a concise question that includes a reference to the object the action is performed upon.
+
You can exclude extra information or form elements in confirmation dialogs, but these should be kept as compact as possible.
constresult=awaitconfirmationFactory()
+.custom("Do you want a cookie?")
+.withoutMessage();
+if(result){
+// User has confirmed the dialog.
+}
+
+
Confirmation dialogs are a special type that use the role="alertdialog" attribute and will always include a cancel button.
+The dialog itself will be limited to a width of 500px, the title can wrap into multiple lines and there will be no âXâ button to close the dialog.
Over the past few years the term âConfirmation Fatiqueâ has emerged that describes the issue of having too many confirmation dialogs even there is no real need for them.
+A confirmation dialog should only be displayed when the action requires further inputs, for example, a soft delete that requires a reason, or when the action is destructive.
The confirmation question should hint the severity of the action, in particular whether or not it is destructive.
+Destructive actions are those that cannot be undone and either cause a permanent mutation or that cause data loss.
+All questions should be phrased in one or two ways depending on the action.
+
Destructive action:
+
+
Are you sure you want to delete âExample Objectâ?
+(German) Wollen Sie âBeispiel-Objektâ wirklich löschen?
+
+
All other actions:
+
+
Do you want to move âExample Objectâ to the trash bin?
+(German) Möchten Sie âBeispiel-Objektâ in den Papierkorb verschieben?
WoltLab Suite 6.0 currently ships with three presets for common confirmation dialogs.
+All three presets require the title of the related object as part of the question asked to the user.
Soft deleting objects with an optional input field for a reason:
+
1
+ 2
+ 3
+ 4
+ 5
+ 6
+ 7
+ 8
+ 9
+10
+11
constaskForReason=true;
+const{result,reason}=awaitconfirmationFactory().softDelete(
+theObjectName,
+askForReason
+);
+if(result){
+console.log(
+"The user has requested a soft delete, the following reason was provided:",
+reason
+);
+}
+
+
The reason will always be a string, but with a length of zero if the result is false or if no reason was requested.
+You can simply omit the value if you do not use the reason.
+
1
+2
+3
+4
+5
+6
+7
+8
constaskForReason=false;
+const{result}=awaitconfirmationFactory().softDelete(
+theObjectName,
+askForReason
+);
+if(result){
+console.log("The user has requested a soft delete.");
+}
+
Modal dialogs are a powerful tool to draw the viewerâs attention to an important message, question or form.
+Dialogs naturally interrupt the workflow and prevent the navigation to other sections by making other elements on the page inert.
+
WoltLab Suite 6.0 ships with four different types of dialogs.
There are four different types of dialogs that each fulfill their own specialized role and that provide built-in features to make the development much easier.
+Please see the following list to make a quick decision of what kind of dialog you need.
+
+
Is this some kind of error message? Use an alert dialog.
Dialogs may contain just an explanation or extra information that should be presented to the viewer without requiring any further interaction.
+The dialog can be closed via the âXâ button or by clicking the modal backdrop.
+
1
+2
constdialog=dialogFactory().fromHtml("<p>Hello World</p>").withoutControls();
+dialog.show("Greetings from my dialog");
+
Dialogs without controls are an anti-pattern because they only contain content that does not require the modal appearance of a dialog.
+More often than not dialogs are used for this kind of content because they are easy to use without thinking about better ways to present the content.
+
If possible these dialogs should be avoided and the content is presented in a more suitable way, for example, as a flyout or by showing content on an existing or new page.
Alerts are designed to inform the user of something important that requires no further action by the user.
+Typical examples for alerts are error messages or warnings.
+
An alert will only provide a single button to acknowledge the dialog and must not contain interactive content.
+The dialog itself will be limited to a width of 500px, the title can wrap into multiple lines and there will be no âXâ button to close the dialog.
+
1
+2
+3
+4
constdialog=dialogFactory()
+.fromHtml("<p>ERROR: Something went wrong!</p>")
+.asAlert();
+dialog.show("Server Error");
+
+
You can customize the label of the primary button to better explain what will happen next.
+This can be useful for alerts that will have a side-effect when closing the dialog, such as redirect to a different page.
+
1
+ 2
+ 3
+ 4
+ 5
+ 6
+ 7
+ 8
+ 9
+10
+11
constdialog=dialogFactory()
+.fromHtml("<p>Something went wrong, we cannot find your shopping cart.</p>")
+.asAlert({
+primary:"Back to the Store Page",
+});
+
+dialog.addEventListener("primary",()=>{
+window.location.href="https://example.com/shop/";
+});
+
+dialog.show("The shopping cart is missing");
+
+
The primary event is triggered both by clicking on the primary button and by clicks on the modal backdrop.
Alerts are a special type of dialog that use the role="alert" attribute to signal its importance to assistive tools.
+Use alerts sparingly when there is no other way to communicate that something did not work as expected.
+
Alerts should not be used for cases where you expect an error to happen.
+For example, a form control that expectes an input to fall within a restricted range should show an inline error message instead of raising an alert.
Confirmation dialogs are supported through a separate factory function that provides a set of presets as well as a generic API. Please see the separate documentation for confirmation dialogs to learn more.
The most common type of dialogs are prompts that are similar to confirmation dialogs, but without the restrictions and with a regular title.
+These dialogs can be used universally and provide a submit and cancel button by default.
+
In addition they offer an âextraâ button that is placed to the left of the default buttons are can be used to offer a single additional action.
+A possible use case for an âextraâ button would be a dialog that includes an instance of the WYSIWYG editor, the extra button could be used to trigger a message preview.
The extra button has no default label, enabling it requires you to provide a readable name.
+
1
+ 2
+ 3
+ 4
+ 5
+ 6
+ 7
+ 8
+ 9
+10
+11
constdialog=dialogFactory()
+.fromId("myDialog")
+.asPrompt({
+extra:Language.get("my.extra.button.name"),
+});
+
+dialog.addEventListener("extra",()=>{
+// The extra button does nothing on its own. If you want
+// to close the button after performing an action youâll
+// need to call `dialog.close()` yourself.
+});
+
You can open a dialog through the .show() method that expects the title of the dialog as the only argument.
+Check the .open property to determine if the dialog is currently open.
+
Programmatically closing a dialog is possibly through .close().
All contents of a dialog exists within a child element that can be accessed through the content property.
+
1
+2
+3
+4
+5
+6
+7
// Add some text to the dialog.
+constp=document.createElement("p");
+p.textContent="Hello World";
+dialog.content.append(p);
+
+// Find a text input inside the dialog.
+constinput=dialog.content.querySelector('input[type="text"]');
+
Fires only when there is a âCancelâ button and the user has either pressed that button or clicked on the modal backdrop.
+The dialog will close if the event is not canceled.
Fires when an extra button is present and the button was clicked by the user.
+This event does nothing on its own and is supported for dialogs of type âPromptâ only.
+
1
+2
+3
dialog.addEventListener("extra",()=>{
+// The extra button was clicked.
+});
+
Fires only when there is a primary action button and the user has either pressed that button or submitted the form through keyboard controls.
+
1
+2
+3
+4
+5
+6
dialog.addEventListener("primary",()=>{
+// The primary action button was clicked or the
+// form was submitted through keyboard controls.
+//
+// The `validate` event has completed successfully.
+});
+
Fires only when there is a form and the user has pressed the primary action button or submitted the form through keyboard controls.
+Canceling this event is interpreted as a form validation failure.
Dialogs are full screen overlays that cover the currently visible window area
using a semi-opague backdrop and a prominently placed dialog window in the
@@ -2986,7 +3048,7 @@ key is .content which holds a reference to the dialog's inner conte
Last update:
- 2021-01-08
+ 2022-10-11
diff --git a/6.0/javascript/new-api_dom/index.html b/6.0/javascript/new-api_dom/index.html
index 0967c160..13990ae1 100644
--- a/6.0/javascript/new-api_dom/index.html
+++ b/6.0/javascript/new-api_dom/index.html
@@ -819,6 +819,67 @@
+
+
+