Settings defaults options semantics #47
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ved the mix of spaces and tabs, adjusted line spacing in these two files for consistency of conceptual segmentation, and made changes to pass jsHint The JQuery Core Style Guidelines can be found here: http://docs.jquery.com/JQuery_Core_Style_Guidelines Adjusted the in-code white-spacing for consistency -- prior to these changes there was no evident standard, or a standard had yet to be enforced. Chose to adhere to jQuery Core Style Guidelines because students studying jQuery will come across many examples authored by core team members who, on balance, tend towards this standard. Fixed one minor jsHint-discovered error, an unnecessary semicolon at the end of a function definition. Stripped-away all trailing spaces on code and blank lines. By the way, I like your use of the leading semicolon to guard against prior concatenated code. Signed-off-by: Steven Black <steveb@stevenblack.com>
…and options. Prior to this change, these two files used settings, something called "defaultOptions", and options. Using "defaultOptions" is problematic because it does not cleanly separate defaults and options. It needlessly confounds the two. The `namespaced-starter.html` file actually fell into this trap. See the comment on line 36 here: chuanxshi@7f3d3d3#jquery-plugin-patterns/namespaced-starter.html Besides "defaults" is a better term than "defaultOptions". This may matter for non-English native readers. THEREFORE options: values provided by the plugin's calling code. defaults: the settings provided A-Priori by the plugin settings: the final, amalgamated run-time spec for the plugin An additional benefit: cleanly separating options, defaults, and settings makes these available for subsequent runs of the plugin without mutating the plugin's defaults, which can be restored at anytime without redefining the plugin. This is not so much a problem for these two examples, but there are other jQuery plugin patterns in this collection where this definitely applies. For example, https://github.com/shichuan/javascript-patterns/blob/master/jquery-plugin-patterns/best-options.html where "options" is (for the moment) used in lieu of settings, thus destroying the user-provided options object. I'll fix that separately. Signed-off-by: Steven Black <steveb@stevenblack.com>
|
@StevenBlack wow, that's very well explained. thanks :) |
chuanxshi
added a commit
that referenced
this pull request
Mar 29, 2012
…tics Settings defaults options semantics
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There are two commits in this pull request, which speaks to the jQuery Plugins Patterns section.
The chronologically first commit is a whitespace cleanup for consistency and to adhere to a standard; I chose the jQuery core standards.
The second commit cleanly separates the concepts of