-
-
Save jordanorelli/5544196 to your computer and use it in GitHub Desktop.
var picker_id = this.id + 'start-date'; | |
this.start_date_picker = this.date_picker_container.append('input'); | |
this.start_date_picker.attr('type', 'text'); | |
this.start_date_picker.attr('id', picker_id); | |
this.start_date_picker = $('#'+picker_id).datepicker(); | |
// this DOES NOT work: | |
this.start_date_picker.setDate(this.response.start_date); | |
// instead, you have to do this: | |
$('#'+picker_id).datepicker('setDate', this.response.start_date); |
I think to call this a "steadfast refusal by the community" is a bit hyperbolic. Your specific example is just the jQuery plugin convention, which I also find pretty annoying. However, since JS only has a global namespace it is important that jQuery doesn't conflict with other scripts that could be loaded on the same page. It's also important that jQuery plugins don't conflict with the canonical library.
However, there are alternative solutions being actively developed to solve this problem, specifically CommonJS used in Node and the AMD pattern, currently used by requirejs (http://requirejs.org, check it out, it's awesome) and will eventually be used in ES Harmony (in some form).
I was thinking of alternative ways you could write your code, and could only really come up with a possibly uglier solution.
this.start_date_picker = $('#'+picker_id).datepicker;
this
.start_date_picker
.call(this.start_date_picker, 'setDate', this.response.start_date);
it's not that hyperbolic a statement - the "community" (if you want to call it that) is not focused on the craft (like the Python community for example) but on creating useable and reusable code usually with production in mind. Since Javascript was written in something like a month by a guy (forgot his name) working at Netscape in an attempt to sail the next cannonball in the ie netscape browser wars - it doesn't have the Guido or the Matz shepherding its development and fostering its community.
Instead it's development is handled by a comity.
I'm sure a lot of this refusal to come up with simplified conventions that you've noticed comes from that fact that it was sort of an orphaned bastard child.
you're right; it's totally hyperbolic. If I've learned anything about commenting on programming, it's that constructive dialogue that isn't completely hyperbolic doesn't get people to pay attention and click on your links.
yep, I'm using requirejs. It's... decently helpful. I'm not so sure my mind is blown but I've found it to be helpful for my project, so I see why people use it. You have to shim jquery-ui but it's not a big deal. It doesn't really clean up this particular problem though.
Anyway, we have some module, and it adds this datepicker
method to the jQuery object (in your example you don't actually call datepicker
but I'm guessing it's just a typo and doesn't merit discussion). All my gripe is that when you run datepicker(), it should return an object that has appropriate methods on it. You'd still only be adding a single method, datepicker, to the jquery object; it's the return value that would get the setDate method.
this is a perfect example of why I hate working with JavaScript: the steadfast refusal by the community to actually create valid types and give them methods. I see this in every JavaScript library I use. You'd think that with a language that lets you modify types so freely, that people would be quite adept at making types, but instead, everything is just Object or Array type. Opaque types everywhere.