Skip to content

Loading…

Add 'data-' attributes to <li>s with 3rd 'selection' param on ranges #76

Closed
wants to merge 1 commit into from

2 participants

@chadoh

In order to hook daterangepicker into our existing app infrastructure,
we needed to be able to pass some custom keys with our ranges. These
keys, for us, correspond to filters defined on the backend that are
already used all over the app.

Really, this implementation feels backwards, but fixing it would require
major breaking changes with the current functionality of
daterangepicker. To us at PipelineDeals, it seems like a better
implementation would be: Have these 'custom keys' replace the current
range keys, and have a third parameter passed to ranges with the "human
name" of the range, which gets displayed in the UI.

I can schedule some time to add some docs for this feature, if you feel
it fits within the scope of daterangepicker.

@chadoh chadoh Add 'data-' attributes to <li>s with 3rd 'selection' param on ranges
In order to hook daterangepicker into our existing app infrastructure,
we needed to be able to pass some custom keys with our ranges. These
keys, for us, correspond to filters defined on the backend that are
already used all over the app.

Really, this implementation feels backwards, but fixing it would require
major breaking changes with the current functionality of
daterangepicker. To us at PipelineDeals, it seems like a better
implementation would be: Have these 'custom keys' replace the current
range keys, and have a third parameter passed to ranges with the "human
name" of the range, which gets displayed in the UI.

I can schedule some time to add some docs for this feature, if you feel
it fits within the scope of daterangepicker.
86b17fc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Mar 12, 2013
  1. @chadoh

    Add 'data-' attributes to <li>s with 3rd 'selection' param on ranges

    chadoh committed
    In order to hook daterangepicker into our existing app infrastructure,
    we needed to be able to pass some custom keys with our ranges. These
    keys, for us, correspond to filters defined on the backend that are
    already used all over the app.
    
    Really, this implementation feels backwards, but fixing it would require
    major breaking changes with the current functionality of
    daterangepicker. To us at PipelineDeals, it seems like a better
    implementation would be: Have these 'custom keys' replace the current
    range keys, and have a third parameter passed to ranges with the "human
    name" of the range, which gets displayed in the UI.
    
    I can schedule some time to add some docs for this feature, if you feel
    it fits within the scope of daterangepicker.
Showing with 8 additions and 3 deletions.
  1. +8 −3 daterangepicker.js
View
11 daterangepicker.js
@@ -143,6 +143,7 @@
var start = options.ranges[range][0];
var end = options.ranges[range][1];
+ var selection = options.ranges[range][2];
if (typeof start == 'string')
start = Date.parse(start);
@@ -167,14 +168,18 @@
continue;
}
- this.ranges[range] = [start, end];
+ this.ranges[range] = [start, end, selection];
}
var list = '<ul>';
for (var range in this.ranges) {
- list += '<li>' + range + '</li>';
+ if (this.ranges[range][2]) {
+ list += '<li data-selection='+this.ranges[range][2]+'>' + range + '</li>';
+ } else {
+ list += '<li>' + range + '</li>';
+ }
}
- list += '<li>' + this.locale.customRangeLabel + '</li>';
+ list += '<li data-selection="custom">' + this.locale.customRangeLabel + '</li>';
list += '</ul>';
this.container.find('.ranges').prepend(list);
}
Something went wrong with that request. Please try again.