Remove CalendarDate argument class for arguments in calendar_datetime

Changing this to Major because it effect a lot of other code

As for the CalendarDate argument handler, that was added specifically to make granularity and range options available on the handler. They serve as a fallback.

Sorry getting my head around this what do you mean by fallback. It seems that if used the specific handler for granularity then they won't need to be on the handler options because by selecting the appropriate argument you won't need them on the options form. But I am probably missing something.

Looking at the 7.x version of the handler, I think there are several more options available. So I don't think we can drop it altogether.

There are some strange options on date_views_argument_handler in D7 that I wonder we should rethink.

For instance Date field(s) which allows you to select multiple date fields

In D7 you added the date argument and then select the field or fields. We as so far in D8 version we have an argument per field made dynamically so selecting multiple fields won't work.

Also the selecting multiple fields for 1 contextual filter makes Date arguments work different then all other contextual filters.

A couple things I am seeing in #2567815: Add week, date, and year-month Views argument plugins

It doesn't actually provide all the granularity arguments we need. What it core would provide with this patch is:

$arguments = [
      // Argument type => help text.
      'year' => t('Date in the form of YYYY.'),
      'month' => t('Date in the form of MM (01 - 12).'),
      'day' => t('Date in the form of DD (01 - 31).'),
      'week' => t('Date in the form of WW (01 - 53).'),
      'year_month' => t('Date in the form of YYYYMM.'),
      'full_date' => t('Date in the form of CCYYMMDD.'),
    ];

The 'week' is not really useable for calendar purposes because it doesn't contain the year. Unless the label is wrong.

For the others we could use these. If need CalendarDate argument but want to use the extra arguments types above we would have to make a class for each formats CCYYMMDD, YYYYMM, and YYYY. Because now CalendarDate extends \Drupal\views\Plugin\views\argument\Date. Since each of the listed formats has it's own class then we would have to CalendarDate SubClasses for each.

For instance for Contains \Drupal\calendar_datetime\Plugin\views\argument\YearMonthDate we would need \Drupal\calendar\Plugin\views\argument\YearMonthCalendarDate.

Does that sound right?

If so we would need to change both hook implementations in calendar.views.inc to instead of making 1 calendar contextual filter for each to actually have 1 contextual filter for each granularity.

Ok after talk with @pjonckiere and @geertvd we figured that we don't actually need the Calendar date class. For now we will use arguments that are in calendar_datetime which are copied from this core patch #2567815: Add week, date, and year-month Views argument plugins

Hopefully the arguments will be include in core 8.1 then we will not need special arguments in this module.

This patch updates calendar_datetime and removes \Drupal\calendar\Plugin\views\argument\CalendarDate class.

There are still problems and this probably creates others.

Known problems

1. The core patch does not create argument for the date format CCYYW(i.e 201525 for the 25th week in 2015)
2. It checks if the arguments extend \Drupal\calendar_datetime\Plugin\views\argument\Date which bring in 8.1 core changes but the year format(CCYY) is already included in core. so this class doesn't extend it. Should probably just change to extend \Drupal\datetime\Plugin\views\argument\Date which all do.

Ok committed to this issue. Closing since removed CalendarDate argument class

Follow up issue for week #2624464: Create Year Week date argument

Follow to fix view template #2624470: Fix "from template" functionality for Date Fields(non-base)