Response title
This is preview!
JQUI Widget Factory: data- overrides passed options, or passed options overrides data- ?
in Developing jQuery Plugins
•
6 years ago
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!)
1