In a jQuery UI Widget Factory widget, is it considered
"kosher" to leave option keys undefined? Or must every option
key be defined?
It would produce different results when you check an option that
might have a boolean value. If the key is defined, then it will return
false. If the
key is not defined, it would return undefined. For a simple
boolean test, it would not make any difference. But I do not know what
code or common practice may lurk that might test for an explicit value
I suppose I just answered my own question - all of the keys should
be defined, because you just don't know how the options object
might be used by application code.
I'm writing a new plugin to replace jquery.mobile.iscrollview,
which is getting long in the tooth, and only supports iScroll4 (and
that only through 4.2). I'm writing a more modular plugin that
will target jQuery, jQuery UI, and jQuery Mobile and wrap IScroll5.
(Will need widget.js for use with
just jQuery.) It will also work more intimately with the iScroll5
code, patching it, for example, to register and trigger events through jQuery.
So, it's basically a wrapper for iscroll5, which is not a
jQuery plugin. It has it's own options object, which I reflect
back to the widget (merging with additional options that only have
meaning to the widget). But iscroll5 omits keys for many options that
default to false.
(iScroll4 did not do this.) So, I am trying to decide how much I need
to massage the iScroll5 options.
To work with the existing iscroll5 script, then, I will need to
create a simple data structure describing some properties of each
possible option. (e.g. is it an iscroll5 option, or an additional
widget option? Is it initialized in in iscroll5, or allowed to be
undefined in iscroll5? Etc.)
Two more questions:
1. Is it at all typical of widgets to have "sub-options"?
iscroll5 has one case of this. It has an option "indicators", which
is an object containing quite a number of options related to
indicators (scroll bars) such as fade, interactive, resize, shrink...
I might merge options found in an object at that key just as done
for options itself, or I might flatten the namespace. e.g. options.indicatorsFade.
Which approach is more "widget-friendly"?
2. iscroll5 "normalizes" options. That is, it will set
some options that are unset in the merge between defaults and your
supplied options. (Rather than to static defaults.) And it will
"fix" some irrational options.
(So, then, I copy back the options to the widget, as I do with the
Is there precedent for this in other widgets? Is this unexpected
behavior of a widget?
I don't see a real problem with this, so long as the
documentation makes it clear. Anybody see other problems with this?
I found a precedent for "sub-options". Really, just an option
that is an object. They aren't very common though, and I guess I
just have to live with the fact that the Widget Factory option support
doesn't deal with them elegantly.
The jQuery UI Button Widget has an option,
is an object used as a hash. So, it's a bit awkward if you
wanted to change only the primary or secondary option - will require
engaging in "bracketry". I assume that it is deep-merged,
so that you can set one without having to set the other?
I think I will abandon the idea of "flattening"
iscroll5's "sub-options", then. It will be a bit
awkward, but consistent with other widgets. There are only two of
these - one is a set of key bindings, and the other is a set of
picayune options dealing with indicators (scroll bars). There are
top-level options that set various combos of the picayune ones. So, if
the user wants to set these very fine-grained options, it will be a
bit awkward for them, but they would be seldom-used.
Leave a comment on watusiware's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic