eternicode/bootstrap-datepicker — pull request #365 by eternicode (2013-02-15 22:44:49+00:00)
Title: Revamp how options are derived, stored, used

## Derivation

Currently each option must be derived individually from passed options, defaults (usually hard-coded), data-attributes, and, in some cases, the active locale. This allows for an incredible amount of inconsistency in implementation from option to option, with each case being based mostly on one's understanding of existing precedent and how one thinks the feature they are working on should be implemented.

Some options have inconsistent associated data-attributes. For example, `startDate` should be `data-date-start-date` (uppercase letter becomes dash plus lowercase letter; `D` -> `-d`), but the code looks for its value in `data-date-startdate`.

## Storage

Currently, all options are stored ad-hoc on the Datepicker instance itself. This is messy, both in code and conceptually.

Instead, options should be stored in an `options` object on the Datepicker instance. Keeping all options in a single, central location -- though still on a per-instance basis -- would not only be cleaner, but allow for easier extensibility going forward. This should also make it much easier to update specific values via functions like `setStartDate` et al.

It may also be beneficial to store the "raw" values (some values, such as `language`, are pre-processed/validated before being set on the Datepicker instance) in a separate object (such as `this._options`).

## Usage

Throughout the code, there's no straightforward way to tell what attributes are options and which are internal/builtin/other attributes. "Storage" above, I think, would make things clearer throughout the code (eg, `this.options.startDate` instead of `this.startDate`).

(Sneak peek: With this ticket, aside from general cleanup, I'm specifically thinking of how to implement a plugin system)