On Sat, Jan 17, 2009 at 11:39 AM, niner <jyi...@gmail.com> wrote:
>
> thanks very much Richard for this clarification. this 'ui' parameter
> sounds like it's really for API specific data rather than user data
> (i.e. lastname, firstname). from reading the documentation, it lead me
> to believe that this is for passing user data into the dialog object.
> so should i still be just using the jQuery .data() mechanism to pass
> around data then?
Yes, .data() is perfect for that sort of thing.
- Richard
>
> thanks,
>
> On Jan 17, 4:04 am, "Richard D. Worth" <rdwo...@gmail.com> wrote:
> > This was actually documentation of an unintended behavior (a bug). I've
> gone
> > ahead and removed that line. A bit of background first:
> >
> > All jQuery UI plugin callbacks follow the same pattern. They receive two
> > arguments. We call these 'event' and 'ui'.
> >
> > callback 'event' argument
> > The first argument (event) is the plugin event which triggered the
> callback.
> > In the case of dialog open, that would be the 'dialogopen' event. This
> also
> > will contain detail about the original browser event that triggered this
> > plugin event. For example you can close a dialog by pressing the Esc key
> > (keypress) or by clicking a close button (click).
> >
> > callback 'ui' argument
> > The second argument (ui) is a bag of data (a hash) that contains useful
> > information that pertains to that particular event that is either not
> > accessible or not convenienyl accessible through other API calls. For
> > example, if you are doing drag and drop, in the drop callback of a
> > droppable, you need a handle to the draggable element which is being
> > dropped. So we provide that in ui.draggable. Here's a code example
> >
> > $("#draggable").draggable();
> > $("#droppable").droppable({
> > drop: function(event, ui) {
> > var drp = $(this);
> > var drg = $(ui.draggable);
> > drp.append(drg.text());
> > }
> >
> > });
> >
> > So $(this) is the droppable element being dropped on. And $(ui.draggable)
> is
> > the draggable element being dropped. Notice how this is specific to this
> > particular instance of the drop event callback? The next time an element
> is
> > dropped (and this callback is triggered), it might be a very different
> > draggable element, so it wouldn't make sense to have this as an option
> api
> > call, for example, like
> >
> > var drg = $(this).droppable("option", "draggable") // not logical or
> > supported - use $(ui.draggable) instead
> >
> > So that's why we have these two arguments on every jQuery UI callback
> > function - 'event' and 'ui'.
> >
> > Back to your specific question about why dialog open's 'ui' argument was
> > documented as containing the options object:
> >
> > In 1.5.3, each callback 'ui' argument contained at least one property
> call
> > ui.options. This contained the current plugin options like you pass to
> init,
> > like
> >
> > var options = { modal: true, autoOpen: false };
> > $(el).dialog(options);
> >
> > This created an API hole. By supplying the options collection, the user
> > could actually make a change to plugin options in a callback function
> > without going through the api. So you could do something like
> >
> > $(el).dialog({
> > open: function(event, ui) {
> > ui.options.width = 650; // bad - doesn't use the API
> > }
> >
> > });
> >
> > This is bad because without using the API, the plugin wouldn't be aware
> of
> > that change, and it couldn't react accordingly. Another reason for
> removing
> > this ui.options is it created an additional way of getting the same
> > information. As I mentioned before, the ui parameter should only contain
> > data that is relevant to this specific instance of this specific event
> > callback, that can't be had coneniently through an existing API. In the
> case
> > of dialog.options.width, there's already an API for getting and setting
> that
> >
> > $(el).dialog({ width: 300 }); // init dialog with width 300
> > var width = $(el).dialog("option", "width"); // get dialog width after
> init
> > $(el).dialog("option", "width", 650); // set dialog width after init
> >
> > So I just checked and currently (1.6rc5) there is no data passed in the
> 'ui'
> > argument to either the dialog open or dialog close callbacks. So this
> sits
> > as a placeholder. If we ever have to pass any relevant data to these
> > callbacks, we'll put it in that hash and document it. Here's an examples
> of
> > documented 'ui' argument hash contents:
> >
> > http://docs.jquery.com/UI/Draggable/draggable#options
> >
> > * ui.helper - the JQuery object representing the helper that's being
> dragged
> > * ui.position - current position of the helper as { top, left } object,
> > relative to the offset element
> > * ui.absolutePosition - current absolute position of the helper as { top,
> > left } object, relative to page
> >
> > - Richard
> >
> > On Sat, Jan 17, 2009 at 3:01 AM, niner <jyi...@gmail.com> wrote:
> >
> > > is there an example of data passing using the "open" option in jQuery
> > > UI dialog? the documentation states that
> >
> > > "The data passed is the opened dialog options object."
> >
> > > but how does that work exactly in code?
> >
> > > thanks,
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery UI" group.
To post to this group, send email to jquery-ui@googlegroups.com
To unsubscribe from this group, send email to
jquery-ui+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-ui?hl=en
-~----------~----~----~----~------~----~------~--~---
