Event bugs

[diogobaeder]

Hi there,

I noticed some bugs while starting to use jQuery UI with dialogs:

1. "dragstop" and "resizestop" are not being triggered, even if I pass
dragStop and resizeStop methods to the option argument. I had to
overwrite these methods to force the triggers;
2. "dialogclose" is not passing ui as argument. The only argument
passed for the event handler is the event object; To have the ui
passed, I have to send it as part of the data argument;
3. Documentation has case problems: the documentation tells about
"dragStop" and "resizeStop" events, but these don't exist. The correct
event types, as implemented by the framework, are "dragstop" and
"resizestop" (notice the letter case difference).

Also, I noticed that the names of the event types and methods are not
as consistent as they could be... do you guys agree?

Thanks!

Diogo

[Scott González]

On Mon, Jun 22, 2009 at 12:32 PM, diogobaeder <diogo...@gmail.com> wrote:

Hi there,

I noticed some bugs while starting to use jQuery UI with dialogs:

1. "dragstop" and "resizestop" are not being triggered, even if I pass
dragStop and resizeStop methods to the option argument. I had to
overwrite these methods to force the triggers;

You're correct, we don't currently have dialogdragstop or dialogresizestop events.  The dragstop and resizestop events do get triggered on the .ui-dialog wrapper element.  Feel free to create a ticket to add the dialog specific events since every callback option is supposed to have accompanying events.
 

2. "dialogclose" is not passing ui as argument. The only argument
passed for the event handler is the event object; To have the ui
passed, I have to send it as part of the data argument;

There is no relevant information to pass here.  What are you looking for?

3. Documentation has case problems: the documentation tells about
"dragStop" and "resizeStop" events, but these don't exist. The correct
event types, as implemented by the framework, are "dragstop" and
"resizestop" (notice the letter case difference).

Can you create a ticket for this as well?
 

Also, I noticed that the names of the event types and methods are not
as consistent as they could be... do you guys agree?

What specifically are you referring to here?

[diogobaeder]

Hi, Scott,

Thanks for the quick reply.

1. Created for "resizeStop" and "dragStop":
http://dev.jqueryui.com/ticket/4629

2. Created for "dialogclose":
http://dev.jqueryui.com/ticket/4630

3. The tiket 4629 covers this;

4. Also covered in 4629, suggested as "dialogresizestop" and
"dialogdragstop" (specific events for the specific component).

Thanks!

Diogo



On Jun 22, 5:38 pm, Scott González <scott.gonza...@gmail.com> wrote:

[Scott González]

On Tue, Jun 23, 2009 at 11:31 PM, diogobaeder <diogo...@gmail.com> wrote:

2. Created for "dialogclose":
http://dev.jqueryui.com/ticket/4630

As I said in my previous post, there is no relevant information to pass in the ui hash, so it is undefined.  Also, the context of the event is in fact the original element, not the wrapper.  I've closed the bug as worksforme.  If you can provide a page showing an actual problem, I'll reopen the ticket.

[diogobaeder]

Well, the "ui" argument should be removed from the documentation, at
least, to avoid confusion, am I right?

Thanks, Scott!

Diogo



On Jun 24, 9:42 am, Scott González <scott.gonza...@gmail.com> wrote:

[Scott González]

On Thu, Jun 25, 2009 at 8:42 AM, diogobaeder <diogo...@gmail.com> wrote:

Well, the "ui" argument should be removed from the documentation, at
least, to avoid confusion, am I right?

Probably.  I believe our docs template actually puts it in automatically because it's a callback and all callbacks receive an event and optional ui hash.  Maybe we should just pass an empty hash instead of undefined.  Would that seem reasonable to you? 

[diogobaeder]

Hmmm... don't know if I understand you... why put an empty hash if it
has no use? Shouldn't the method signature be as clean as possible?

Thanks, Scott!

Diogo



On Jun 25, 9:56 am, Scott González <scott.gonza...@gmail.com> wrote:

[Scott González]

Hey Diogo,

I just talked to some of the other team members and we agreed that passing an empty hash makes sense in this case.  The reason we would provide an empty hash is because we essentially have an interface defined by our standards, without having an actual interface to force the function definitions to match.  Part of our standard for widgets and interactions is that all callbacks have associated events and both the callback and event will always receive two parameter: the event object and a hash containing information relevant to the event.  In the case where there is no information relevant to the event, we will provide an empty hash.

I've created a ticket for this: http://dev.jqueryui.com/ticket/4650

[diogobaeder]

Oh, got your point, Scott... great, then! :-)

I'll read more carefully the UI plugin specs, to avoid further
confusion... thanks!

Diogo

On Jul 1, 3:01 pm, Scott González <scott.gonza...@gmail.com> wrote:
> Hey Diogo,
>
> I just talked to some of the other team members and we agreed that passing
> an empty hash makes sense in this case.  The reason we would provide an
> empty hash is because we essentially have an interface defined by our
> standards, without having an actual interface to force the function
> definitions to match.  Part of our standard for widgets and interactions is
> that all callbacks have associated events and both the callback and event
> will always receive two parameter: the event object and a hash containing
> information relevant to the event.  In the case where there is no
> information relevant to the event, we will provide an empty hash.
>
> I've created a ticket for this:http://dev.jqueryui.com/ticket/4650
>