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...
) 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
binding). It seems to me
now that perhaps they should be permitted to, but that in
itself is really a different (JQM-specific) issue.
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
attribute or attributes?
data- attributes into the
constructor attributes? Or merge the constructor attributes into the
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?
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
options, in a more
JQM-kind of way.
That is, the
options set using a JSON string above, might also be set
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
particularly lend itself to messing with options once initialized,
though I will try to support that to the extent possible. In
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!)
I think now that the way I have used data-iscroll
is wrong, and a bit off from typical plugin usage.
I used it for both auto-initialization (jQuery Mobile) and for
setting options. I think for setting options with a JSON string (still
unprecedented, at least in JQUI and JQM widgets I have seen) it should
The other thing I was trying to do with data-iscroll was to make
it easy to auto-initialize on any element including data-role="content".
JQM really does not anticipate two widgets on the same element - the
attribute precludes that. I didn't want to force the user to add
an extra <div> to wrap it.
I liked the ease of simply adding data-iscroll to the
content div, which is the most common usage.
But now that (in JQM 1.4) content is no longer a widget, but just
some CSS styling, I think I will follow the data-role standard, as
little as I like it. I see that now there is a provision for globally
setting the selector to be used for auto-initializing a widget, and so
the user has a choice here anyway. so, like data-role="iscroll",
at least for JQM auto-init.
I think I will have a global auto-initialize=true/false option,
which will default to true for JQM and false otherwise. I haven't
seen JQUI widgets that initialize themselves at DOM ready, but why not
offer the option for JQUI and JQ?
So, I think stepping back from it for a while, as well as taking a
good look at some JQUI widgets (I don't use JQUI myself) has
brought some clarity. As well as looking at some improved design in
the more recent Widget Factory.
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