Consistent use of modal dialogs

[manuelbernhardt]

At the moment, our use of dialogs is not consistent: some can be resized and moved, some can be resized but not moved, some can be moved but not resized, ...

It makes sense to separate dialogs in several categories depending on their purpose, and to actually write a couple of helper methods in tm.js so that we clearly make use of those categories.

The general signature of a dialog function should be like this:

function someDialog(title, message, ..., options)

options is an optional object of options that makes it possible to override/extend the options array of the default dialog if needed. That is probably going to be used mostly for adjusting the size of a dialog.

Overriding works like this:

var parameters = { foo1: bar1, ... };
var options = $.extend(parameters, options);
$().dialog(options);

There seem to be the following categories of dialogs, feel free to add more of them:

• information messages, simply showing something to the user, with a "Close" or "Ok" button (and maybe an information / warning icon). Should not be resizable or moveable, nor closeable (cross on top right).
• confirmation messages, not resizable, not closeable, but moveable (if the guy wants to look at something he should be able to do so)
• dialogs with a form inside. Those probably require some custom handling for "save" so they should be additional parameters: one for the text for the save button, one for the save callback and one for the cancel callback (no need to customize "cancel"). Also these dialogs should be moveable, closeable, perhaps resizable (not sure tough).

@gwenael-alizon maybe you can go over this list and add stuff

[manuelbernhardt]

I'm reassigning this one to @dziga, we only need some input on the 3 proposed types from @gwenael-alizon

[gwenael-alizon]

I believe that the 3 types mentioned cover all the cases.

Regarding type 3, dialogs with a form in side, it might indeed come handy at times for a user to be able to resize it. He will probably mostly want to increase the width to take advantage of a bigger portion of his/her screen. This strikes me in particular in test execution, where at the moment step description is quite constrained in its current width. The other option is of course to simply review the width of the different modals and adjust depending on the expected amount of data. Actually that should be done anyway at some point, regardless whether we let the user resize or not, to make sure that the default size is suitable. But I suppose it does not harm to let the user a bit in control there.

[dziga]

I ended up with 4 types.

• info dialog
• confirmation dialog
• form dialog
• tree dialog (same as form, but different shape/size, due the nature of the tree)

There is one global method called in header applyDialogStyles() which triggers creation of all dialogs. It is enough just to give a proper class to a div.

Additional options are added i.e. $(#element).dialog("option", "buttons", 'Close' : function ( ) { $(this).dialog('close') } ) and it has to be triggered by an event such is click on button or table row selected, it won't apply this options on document loaded or ready.

Not sure if this is the best solution, but I have it in separate branch at the moment.

Also, not sure how to threat dialogs such are admin->projects->adding tag or adding role

[manuelbernhardt]

could you push out the branch?

Additional options are added i.e. $(#element).dialog("option", "buttons", 'Close' : function ( ) { $(this).dialog('close') } ) and it has to be triggered by an event such is click on button or table row selected, it won't apply this options on document loaded or ready.

so this means every time a button is clicked for e.g. opening the form, it does add again the configuration in the options array of the dialog? looks a bit like an overkill. how come this is not initialized on document ready ? this does sound somewhat strange.

Also, not sure how to threat dialogs such are admin->projects->adding tag or adding role

isn't that like a confirmation dialog?

[dziga]

could you push out the branch?

pushed.

Additional options are added i.e. $(#element).dialog("option", "buttons", 'Close' : function ( ) { $(this).dialog('close') } ) and it has to be triggered by an event such is click on button or table row selected, it won't apply this options on document loaded or ready.

so this means every time a button is clicked for e.g. opening the form, it does add again the configuration in the options array of the dialog? looks a bit like an overkill. how come this is not initialized on document ready ? this does sound somewhat strange.

it doesn't add, but overwrites an option or options (array), usually those are buttons. I don't know why it can't add them on document ready... probably because it creates dialogs initially on document ready, not sure. I should check once more.

Also, not sure how to threat dialogs such are admin->projects->adding tag or adding role

isn't that like a confirmation dialog?

we could say that, all tough it has input fields which is more similar to form, but in my opinion, it also fits better under confirmation dialog.

Reply to this email directly or view it on GitHub: https://github.com/manuelbernhardt/tm/issues/36#issuecomment-1609755

[manuelbernhardt]

it doesn't add, but overwrites an option or options (array), usually those are buttons. I don't know why it can't add them on document ready... probably because it creates dialogs initially on document ready, not sure. I should check once more.

javascript evaluates top-bottom so you need to make sure you initialize the options prior to any dialog construction

[dziga]

javascript evaluates top-bottom so you need to make sure you initialize the options prior to any dialog construction

didn't really think about it :P I've put initialization of modal dialogs at the end and it works now, pushed to the branch. I think it can be merged now.