In a widget using jQuery UI Widget Factory, sometimes options can be set with
data- attributes. It's common in jQuery Mobile.
I don't think there is really any standard for this, though?
In
jquery.mobile.iscrollview, I let the user override options by setting a JSON string in the
data-iscroll attribute in the HTML. e.g.:
<div data-iscroll='{"scrollbars":false,"useTransform":true}'>
I think that the use of a JSON string here is actually either unprecedented or at least uncommon. It's certainly not the way jQuery Mobile widgets typically set options using data attributes. JQM tends to use a hodgepodge of multiple ad-hoc
data-
attributes, which may or may not actually correspond to actual internal options, but I digress...
( In
jquery.mobile.scrollview
) I didn't give any consideration at all to passing options as a hash parameter to the widget constructor, because in JQM it isn't normal for the user of the widget ("end-developer") to initialize the widget themselves. (It's done for them in
pagecreate -
the widget is expected to supply a
pagecreate
binding). It seems to me now that perhaps they should be permitted to, but that in itself is really a different (JQM-specific) issue.
Anyway, I've been working on
jquery.iscroll
,
which is meant for jQuery, JQUI, or JQM. And, certainly when using just jQuery, it is quite common to write call to the constructor (factory function) in one's own JS code. And, of course, you can pass an options hash.
Any suggestions as to which should override which, should the user provide both an options hash in the constructor, as well as options as a
data-
attribute or attributes?
Merge the
data-
attributes into the constructor attributes? Or merge the constructor attributes into the
data-
attributes?
I *think* the proper answer is that the constructor attributes should go first, and then any options supplied in the HTML as
data-
attributes should then be merged-in. After all, it is
_create()
which must read any data- options, and from the viewpoint of the developer, it is the constructor that starts the ball rolling. Make sense?
But it's possible to merge it either way.
BTW, just to drive developers a bit insane, but to also fully flesh-out the possible ways of initializing options, ( I like orthogonality) I do plan to also allow the developer to set individual options with individual
data-
options, in a more JQM-kind of way.
That is, the options set using a JSON string above, might also be set like this:
<div data-iscroll-scrollbars='false' data-iscroll-useTransform='true'>
I want to make it easy for the developer to set options in the most natural way that makes sense for the particular project. Often, that might be in the HTML, where it self-documents how the widget might be expected to behave, when coming-across the widget in the HTML source. At least for the simple case where a few options are being set statically at initialization, and not being flippped-about later.
iScroll doesn't particularly lend itself to messing with options once initialized, though I will try to support that to the extent possible. In
jquery.mobile.iscrollview
I deal with that fact by re-constructing the widget when calls are made to set an option or options. Yuk! iscroll5 is better at this, though, and quite a few options can be safely changed.
Any comments on other issues I mentioned above are appreciated, but mainly I am looking right now for opinions on order of application of options supplied via constructor hash vs
data-
attributes.
(BTW, Keith, just ordered your book which I hadn't known existed, and eagerly awaiting it's arrival!)