A way to access original options object on widget's creation

Why are you setting a default value for the data store? You'll need to provide realistic use cases for us to even consider this.

Ok, I will try to be as specific as I can.

Here is a hypothetic case:

1. We have a "commonDataStore" object:

    var commonDataStore={name: "Steven", age:15, location: "USA"}

2. We have 3 "myInput" widgets bound to this data store object, created as follows:

    $("#nameInput").myInput({field:"name", dataStore:commonDataStore});    
    $("#ageInput").myInput({field:"age", dataStore:commonDataStore});
    $("#locationInput").myInput({field:"location", dataStore:commonDataStore});

3. The widgets purpose is to save their value to the common data store object for further processing, either by a web application itself, or to send the entire object to the server via AJAX request or whatever. The widgets themselves are doing this for example every time they loose focus. In order to do so, the widgets must know what common object they are using, and I think the most obvious way to do this is to provide this common data store object when they are created. But, with current implementation of widget factory, when "_create" method is invoked, all pure objects in "this.options" are already deep copied, and extended with default options if available. So, the widgets receive a copy or the "commonDataStore" object instead of the object itself. And, I cannot find any "legal" way to get access to the original data store object other than providing it explicitly after the widgets are created:

   $("#nameInput").myInput("option","dataStore",commonDataStore);
   ....

So, I think it will be a nice feature if at least the widget's "_create" method has access to the options as provided on creation, not only the copied and extended version of them. For the moment, only the internal "_createWidget" method has access to them. In fact this method itself is making the copy of the options and extends them with defaults.

This overload works and solves the problem, but _createWidget is internal non-documented function, and I think it is not a good practice to use it:

        _createWidget: function(options){
            this._options = options; //alt: this.dataStore=options.dataStore;
            this._superApply(arguments);
        },

Just make your data store use a real constructor and you won't have a problem. Only plain objects are extended.

Replying to [comment:3 scott.gonzalez]:

Just make your data store use a real constructor and you won't have a problem. Only plain objects are extended.

For several reasons, I cannot. The data store object in my case is a part of array of plain objects, and the array is a result of AJAX response which the browser itself already parsed. Changing records in the array to use constructors may be a performance penalty - there may be thousands of records in the array.

Anyway it was just a proposition. I think it would be a good practice to give a way for widget instance to decide how to extend it's options out of the default behavior.

P.S.: Another possible way to do this is to make _createWidget function to use "this._extendOptions" instead of "$.widget.extend", This way, it will be possible to overload the default behavior in widget's definition. Another possible way is to make "_createWidget" to call "this._extendOptions", defined in Widget prototype, which then, if overloaded, will be able to decide if and when to use "$.widget.extend".

As far as I can see, up to version 1.8, the options are copied with "$.extend(true,...)" instead which creates copies of Arrays also. Then, in 1.9 and up to 1.11 it uses "$.widget.extend" which does not copy Arrays. This creates incompatibility issues. All this can be avoided in future versions just by providing a documented way for a widget to decide what to do with it's options on creation.

So provide the array, that also won't get clobbered. There are already two ways to handle this, we're not going to add a third.

Replying to [comment:5 scott.gonzalez]:

So provide the array, that also won't get clobbered. There are already two ways to handle this, we're not going to add a third.

Forget about the exact case I provided. My proposal was not to create a third or fourth way to do something, but to think about how/if it is possible to overcome this restriction once and for all for any case in any future versions of the widget factory.

Replying to [comment:6 sparkybg]:

Forget about the exact case I provided.

Sorry, without specific use cases, nothing ever gets added.