Hi,
Thanks for your feedback on the date picker... I'll address your points
below:
Rob Desbois wrote:
Well, I've finally taken the plunge and started playing with datePicker.
Can I join everyone in thanking you for this excellent plugin.
Thanks :)
Suggestions for a few changes, mainly ones which increased the time it
took for me to integrate it into a page without hacking the source:
== Change the clickInput option to be clickElement instead ==
I wanted to use <span> as my datePicker element to prevent manual
editing: forcing the use of a text input means making it disabled and
re-enabling it on form submission, or using javascript to prevent
modification.
Click input is a special case which relates to an input field. When a
date is selected the .text property of the input field is updated. So it
wouldn't work too well on any other type of element. What you are
trying to do is better achieved another way... Check out this example:
http://kelvinluck.com/assets/jquery/datePicker/v2/demo/datePickerListen.html
You would want to use a custom listener like that and instead of my
console.log line you would want to do something like:
$(this).text(selectedDate)
You would probably also want to update a hidden input field (if you need
to be able to submit these dates as part of a form).
== Change the <a> created with createButton:true ==
I like the automatic creation of the <a> but dislike the default content
being text and the image being background: it means either CSS is
required to hide the content or JS to remove the content and CSS to
display properly. I've had to resort to adding my own <a> in the HTML
and setting its behaviour myself:
<a href="javascript:choose_date('dateFrom')">
<img src="/images/calendar.gif" alt="[choose date]" />
</a>
I put the text as the content of the link because it seems to be most
semantically correct. It will also work best with screenreaders and
other assistive technology. I figured you could do anything you wanted
to effect it's appearance using CSS (which is after all where you are
meant to control the presentation of your page). It seems cleaner to me
this way (seperating content from presentation).
My suggestion would be to allow the content of the <a> to be set in the
options if desired.
I guess this could be a good compromise (although it will add a little
to the already quite large size of the plugin). If enough people wanted
I can add this option in.
Also, is there a particular reason why $.dpDisplay() returns a value? It
means that to use it from the href of an <a> it has to be wrapped in
another function call returning nothing to prevent the browser from
navigating away when it's called from the href.
Yes. dpDisplay returns a jQuery object so that it is chainable. You
shouldn't be calling it from the href of a link anyway - it is mixing
behavior with content. If you really want to call it from a href you
could wrap it in a void(). But don't forget to also return false.
Alternatively, you could put it directly on the onclick handler in the
link. However, by far the preferred method is to dynamically bind it
onReady like is done in my example linked above. This seperates
behaviour and content cleanly.
Just as an aside: the first sentence of documentation of dpSetOffset()
on
http://kelvinluck.com/assets/jquery/datePicker/v2/demo/documentation.html
<http://kelvinluck.com/assets/jquery/datePicker/v2/demo/documentation.html>
is from the dpDisplay() function instead.
Thanks! I'll fix that over the weekend.
Is datePicker v2 still considered to be in beta?
Yes. Although a stable beta. I don't see any reason not to use it but
there are a couple of extra features I want to add into it before
progressing it beyond beta.
Apologies for length, and many thanks for this damn good piece of kit :-)
--rob
Thanks for the feedback, glad you like the date picker,
Cheers,
Kelvin
