Ticket #4869

Ticket #4869

I looked into both #4869 and #4404 and found both are caused by
essentially the same problem. In both tickets, options set after a
widget is initialized result in the option being set for that
instance, but the necessary UI changes aren't made because they are
buried in the _init() methods, and not handled outside of the init
routine.
For example, in #4869, using the appendText option as shown in the
'setter' example on the demos page would set the option (i.e. after
calling the setter, the getter returns what one would expect), but the
text is only appended if you specify it when initializing the
datepicker.
I created a patch to correct that issue, but since it's not a complete
fix for the ticket, I didn't attach it. The other problem explained in
#4869 is that setting any option on a datepicker instance results in
the initial value of that field being converted to a valid date. For
example:
<input type="text" name="datepicker" id="datepicker" value="Foo"/>
$('#datepicker').datepicker();
$('#datepicker').datepicker('option', 'appendText','Bar'); // input
value will change to current date
As far as I can tell, calling _setDateDatepicker at the end of
_optionDatepicker() should only be necessary if an option is set that
would require the date be updated (e.g. 'dateFormat'), perhaps
something like the _setData() method in the dialog implementation.
Anyways, I thought I should ask about this in case refactoring to
cover this is planned in the future. I see "Re-factor the code to
better match the jQuery UI API" is one of the items listed on the
planning wiki.
Also, I left notes on #4762 and #4257.
Cheers,
--Brandon
--