selectWeek processing has a logic error

[Tino Brackebusch]

Hello Keith,

while updating from 4.0.6 to the lastet stable version i refactored my code too and found out that there is a difference between a selected single date processing queue and a selected week processing queue. I debugged the related functions using console and found the following to happen for a single date selected:

entered _selectDatePlugin
   entered _updateInput
      ... calling onSelect-handler
   passed _updateInput

   entered _update
      ... is inline || plugin.curInst == inst
      ... is inline
   passed _update
passed _selectDatePlugin

the following log refers to a week selected:

entered renderer.onWeekHeader-clickhandler
   entered _setDatePlugin
      entered _update
         ... is inline || plugin.curInst == inst
         ... is inline
      passed _update

      entered _updateInput
         ... calling onSelect-handler
      passed _updateInput
   passed _setDatePlugin
passed renderer.onWeekHeader-clickhandler

Notice the inverse call order of _update() and _updatePlugin(). For week selections this causes the onDate handler to be executed before the onSelect handler, whereas they're executed in correct order for single dates selected (onSelect before onDate). This furthermore prevents for instance changed CSS classes for each of these dates, that are registered in an external object by the onSelect handler, not to be applied before picking another date, because while the related date is processed by onDate, the new CSS class cannot be found, because it is registered afterwards.

For testing i inverted the calls for _update() and _updatePlugin() in _setDatePlugin() lines 1524 and 1525, which is how it is implemented in _selectDatePlugin(). This solves the issue. onSelect is now executed before onDate and a color change works as intended.

// before
if (!setOpt) {
   this._update(target);
   this._updateInput(target, keyUp);
}

// after
if (!setOpt) {
   this._updateInput(target, keyUp);
   this._update(target);
}