[jquery-ui commit] r2177 - trunk/ui

[codesite...@google.com]

Author: rdworth
Date: Tue Mar 3 02:29:18 2009
New Revision: 2177

Modified:
trunk/ui/ui.dialog.js

Log:
Dialog: fix dialog height from being reset after drag in Safari. related to
r2152 and #4252

Modified: trunk/ui/ui.dialog.js
==============================================================================
--- trunk/ui/ui.dialog.js (original)
+++ trunk/ui/ui.dialog.js Tue Mar 3 02:29:18 2009
@@ -341,6 +341,8 @@
handles: resizeHandles,
stop: function() {
$(this).removeClass("ui-dialog-resizing");
+ options.height = $(this).height();
+ options.width = $(this).width();
(options.resizeStop && options.resizeStop.apply(self.element[0],
arguments));
$.ui.dialog.overlay.resize();
}

[Scott González]

We need to decide if this is the correct behavior and then document whatever we decide.  Prior to this commit, if you opened and dialog, resized it, closed it, and reopened it, it opened at the original size.  After this commit, the options will be modified after resizing, so closing and reopening the dialog will result in the dialog being the same size it was when it was closed.

[Andrew Powell]

Perhaps something as simple as options.originalSize could be used to
negate that effect?

2009/3/18 Scott González <scott.g...@gmail.com>:

[Richard D. Worth]

I feel like we've got the correct behavior now. If you close a dialog, everything about its state should maintained except that it's hidden. And we don't really differentiate between options and state, for things like this. This means we should do the same thing with position. If you want to open at some width and height and position again, set those values before calling open. Or destroy it and open a new dialog. Otherwise we should respect the position and size chosen by the user (by dragging and resizing). Thoughts?

- Richard

2009/3/18 Scott González <scott.g...@gmail.com>

[Richard D. Worth]

Another option would be to pass a hash to the open method, containing width, height, and position.

- Richard

[Andrew Powell]

I'm going to have to agree with Scott on this one. Users *have* been
known to do crazy things like resize a dialog just for the sake of
doing so. If we're using a dialog for say, data entry in an enterprise
app, we'll want to enforce that the dialog always looks the same when
it opens, unless the user chooses to resize it. (Some of our users
arent that savvy, and that would confuse them pretty easily) Every
time the particular dialog opens it really should return to it's
default. If we've specified width: auto and the height is also auto by
default, it should really default back to that the next time it's
opened. (In this particular scenario) Sure, we could just instruct
people to reset the width and height options on open, but we're trying
to make things easier for the developers using this, no?

I really think that an option to specify the default behavior in this
case would be a good compromise. It seems like there are good
arguments for both.

[Richard D. Worth]

On Thu, Mar 19, 2009 at 7:32 AM, Andrew Powell <pow...@gmail.com> wrote:

I'm going to have to agree with Scott on this one. Users *have* been
known to do crazy things like resize a dialog just for the sake of
doing so. If we're using a dialog for say, data entry in an enterprise
app, we'll want to enforce that the dialog always looks the same when
it opens, unless the user chooses to resize it.

The user chose to resize it, so it should open at the size they chose to resize it to. This is the same dialog being re-opened, not a new dialog being opened.

- Richard

[Andrew Powell]

Different strokes for different folks then I suppose. As a dev, if I
have a dialog which is being reused for data entry (and being reused
for adding and editing of items on the same page) then I'm going to
want to enforce that the dialog has the same look every time it comes
up 'fresh'. Part of the bonus with using the dialog is reuse and not
having to destroy it each time I want to show it anew.

Such an option to differentiate between behaviors (keeping the resized
size, or resetting to the default upon show) would really be a
value-add for developers using the plugin.

[Richard D. Worth]

-1 for a new option

Either open is showing the dialog in the same state (where 'close' simply hides, 'open' simply shows) or open should show the dialog with the original specified size and position.

- Richard

[Andrew Powell]

In this case, aren't options just that, optional? They exist to expand
the functionality of the plugin for different use-cases, do they not?

Please do explain why you're against adding an option for this. I
think hearing arguments for both positions would be beneficial.

[David Muir]

Can't this already be done by doing something like:

$(selector).data('initWidth', 500).dialog({
    open: function(){
        var $this = $(this);
        $this.dialog('option', 'width', $this.data('initWidth'));
    }
});

I'm assuming that "this" within the open event refers to the dialog element itself. The documentation doesn't say, and I haven't bothered to test it myself.

Cheers,
David

[Richard D. Worth]

On Thu, Mar 19, 2009 at 7:51 AM, Andrew Powell <pow...@gmail.com> wrote:

In this case, aren't options just that, optional? They exist to expand
the functionality of the plugin for different use-cases, do they not?

Not in every case will we add an option. Only where it covers the needs of 80-95% of users or use cases. Otherwise it can be handled manually, through a callback, through an extension.
 

Please do explain why you're against adding an option for this. I
think hearing arguments for both positions would be beneficial.

I'm against adding an option because it's bloat. We didn't get here because users have a need to specify how the open method behaves. We got here because we worked around a bug in one browser introduced by adding a feature where you can drag the dialog around and hide the contents using css, and when you're done dragging the content shows again, but while you're dragging the dialog remains the same size (despite the content being hidden). The side-effect is we changed the default behavior of open, causing us to discuss the default behavior of open.

We're on shaky ground as it is discussing "original values", since we have no distinction (nor do I think we should) between options from defaults, options set at init, options at the time the dialog is first opened (could be after init; width, height, and position could've changed since then), and current state. We have just one collection: options. At the time of init, it represents the options passed to init merged with the defaults. From then on, it represents the state of the plugin. For example:

$("#slider").slider({ value: 15 });
$("#slider").slider("value", 75);

Neither the slider nor the widget plugin keep track of the value that was passed at init (15). If the user wants to, they can store it in a hash, and pass that hash to init. Bringing it back to dialog, if I call

$("#dialog").dialog({ position: 'center' });

and then I call

$("#dialog").dialog("option", "position", [10, 10]);

then say I close the dialog and re-open it. Should it open at 'center' or [10, 10]? We make no differentiation (nor do I think we should) from the user changing the state of a plugin (using the mouse or the key, or from a developer (or some other code) changing the state of a plugin. Another example:

$("#dialog").dialog({ position: 'center', autoOpen: false });
$("#dialog").dialog({ position: 'top' });
$("#dialog").dialog("open").dialog("close").dialog("open");

One more:

$.ui.dialog.defaults.position: 'top';
$("#dialog").dialog();
$.ui.dialog.defaults.position: 'center';
$("#dialog").dialog('close').dialog('open');

The dialog has as a default to autoOpen on init, but I'm not sure calling the open method should otherwise have any tie to what the init state (or the first open state) of the dialog happened to be.

- Richard
 

[Scott González]

I see two distinct, and both very common, uses of dialog.  One use is where the contents of the dialog change on every open.  Devs do this to use the dialog plugin as a wrapper and generally only ever have one dialog open at a time, the contents are dynamically loaded based on some user action for every open.  The other use is where the contents of the dialog are static.  Resetting position and size on open makes sense for the former, and keeping the state at time of close makes sense for the latter.

Because of these two common use cases, I was hesistant to pick a side when I wrote my original message.  Now I'm leaning toward the idea of remembering the state and telling users if they want a "fresh" dialog, they should reset the options prior to opening.

[Andrew Powell]

All good points, Richard. I'll concede that the default position can
be easily reset. I don't think that was in question. However, I'm
still in favor of an option for this. When I'm developing something
that will see a mass amount of reuse (such as a plugin) I always opt
for the path that leads to me having to write less code in the long
term.

[Andrew Powell]

Sounds like I'm the lone proponent of something built into the plugin
for this one :) Call it a difference in dev methodology I suppose.
Good discussion, none the less.

2009/3/19 Scott González <scott.g...@gmail.com>:

[Scott González]

On Thu, Mar 19, 2009 at 9:33 AM, Andrew Powell <pow...@gmail.com> wrote:

Sounds like I'm the lone proponent of something built into the plugin
for this one :) Call it a difference in dev methodology I suppose.
Good discussion, none the less.

I was with you on this for a long time, especially thinking about the case of auto-sizing.  I'd like to write a snippet of code that will revert the functionality back to what it used to be after we make the changes we've discussed in this thread (we still need to update position after drag).  Then we if people want the old functionality, we can point them to the block of code that will do it for them.

[Eduardo Lundgren]

2009/3/19 Scott González <scott.g...@gmail.com>:

This solution sounds good for me too.

>
> >
>



--
Eduardo Lundgren
Software Engineer
Liferay, Inc.
Enterprise. Open Source. For Life.

[Scott González]

Finally created a ticket for this: http://dev.jqueryui.com/ticket/4679