Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#3025 closed enhancement (fixed)

Design Request: data, dataProviderClass, store, url attributes for widgets using

Reported by: haysmark Owned by: bill
Priority: high Milestone: 0.9beta
Component: Dijit Version: 0.9
Keywords: Cc:
Blocked By: Blocking:


Not all of our widget users are going to want to be bothered with stores. Rather, I bet that most people will want to specify a widget's data source directly in the HTML, similar to how you can set the contents of a frame in the HTML.

With 3 lines of code in postCreate, AutoCompleter? and Select already give this versatility. Basically, you can pass the widget itself to the item store constructor, and the store will have direct access to any attributes in the HTML that are relevant to Namely:

// store: Object
//		Reference to data provider object created for this widget
store: null,

// dataProviderClass: String
//		Name of data provider class (code that maps a search string to a list of values)
//		The class must match the interface demonstrated by
dataProviderClass: "",

// url: String
//		URL argument passed to data provider object (class name specified in "dataProviderClass")
//		An example of the URL format for the default data provider is
//		"autoCompleterData.js"
url: "",

// data: Object
//		Inline data to put in store
//		Data must match data type of dataProviderClass
//		For example, data would contain JSON data if dataProviderClass is a JsonItemStore

Here is the code that would go in postCreate of any widget using

     var dpClass=dojo.getObject(this.dataProviderClass, false); dpClass(this);

This simple addition to postCreate opens a slew of new options to the user. Now our users can assign a widget its data in the HTML using any combination of:

  • dataProviderClass and data (they would write raw JSON or XML data into the data attribute of the widget)
  • dataProviderClass class and url (url="autoCompleterData.json")
  • store (as before)

It's so simple, it would be silly not to implement in our other widgets.

Change History (7)

comment:1 Changed 14 years ago by skinner

Is the "dataProviderClass" property always used to specify the name of a class that implements the datastore APIs (rather than some other sort of data provider)? If this is only for datastore classes, I think the name "dataProviderClass" isn't as good as some more specific name, like "datastoreClass".

~ skinner

comment:2 Changed 14 years ago by haysmark

Right, it's for a store. dataStoreClass sounds fine to me.

comment:3 Changed 14 years ago by bill

Component: WidgetsDijit

So we now have this syntax (as shown in themeTester.html):

<div dojoType="" jsId="continentStore"

followed by

<div dojoType="dijit.Tree" store="continentStore" query="{type:'continent'}"
labelAttr="name" typeAttr="type"></div>

That's fairly easy to use and somewhat more versatile, since the store can accept any parameters it wants.

Not sure a mixin adds enough value to be worth it. (If we don't do the mixin then we shouldn't have those extra parameters for Autocompleter/Select? either)

comment:4 Changed 14 years ago by bill

Milestone: 0.90.9beta
Status: newassigned

See also #3020

comment:5 Changed 14 years ago by bill

OK, I've thought over this one. Those parameters might be convenient to the user but dijit operates on the general principle of not providing two ways to do the same thing, and this case isn't important enough to make an exception for. I'm gonna change Combobox/FilteringSelect? to require a store to be declared separately, rather than making all related widgets have multiple ways to specify the data. Sorry.

comment:6 Changed 14 years ago by bill

Resolution: fixed
Status: assignedclosed

(In [9275]) Refactor Combobox and FilteringSelect? to require data store to be specified externally or as <option> tags. Other ways of specifying data removed.

Cleaned up code to read <option> tags to use dojo.query().

Fixes #3025.

comment:7 Changed 14 years ago by bill

(In [9276]) Forgot to update some test files. Refs #3025.

Note: See TracTickets for help on using tickets.