TODO list :

• [x] Implement a factory class
• [x] Use the Symfony option resolver to manage options (class names, first weekday)
• [x] Remove all period instantiations and replace by factory calls
• [ ] Enhance tests code coverage
• [ ] Refactor
• [x] Bump version to 1.1
• [ ] Rewrite obsolete parts of documentation
• [ ] Review, review and review

I need an alternate Week that only iterates over weekdays (that is, excluding Saturday and Sunday). I thought perhaps a more general solution would permit others to address their own needs to integrate alternate period classes.

This PR offers the ability to supply the names of alternate 'dayClass', 'weekClass', 'monthClass' and/or 'yearClass' in an associative array:

-- as a third parameter to the constructors of the existing Week, Month and Year classes (so that they use any specified alternate period in their iterators and the Days array in the case of Month.

-- as the parameter to Calendar::setClasses.

I do have some code implementing feature request from issue #8, but I am not very happy about it. It adds a static variable $firstWeekday to the Calendar class that one can modify before making any other object or calling a method.

One should add some tests as this is a large change in calendar handling. Sorry about the code drop like this but it may be more useful than continue to keep it for myself.

This is a dump of February 2015:

Month {#2306 ▼
  -current: null
  #begin: DateTime {#2288 ▼
    +"date": "2015-02-01 00:00:00"
    +"timezone_type": 3
    +"timezone": "Europe/Rome"
  }
  #end: DateTime {#2295 ▼
    +"date": "2015-03-01 00:00:00"
    +"timezone_type": 3
    +"timezone": "Europe/Rome"
  }
  #firstWeekday: 1
}

I'd expect to see it ending 2015-02-28, not 2015-03-01.

Another attempt at adding this functionality. The firstweekday numeric parameter is replaced with an options array parameter than can include a 'first_day' numeric element to change the week's first day from the default of Monday, and can also specify the names of one or more alternate period classes to use in place of Day, Week, Month, Year and/or Range.

Hi,

Period doesn't have the same meaning in English and in French. Here is my best example: http://www.tampax.co.uk/en-GB/periodCalendar/periodCalendar.aspx.

Time Periods

• Created the classes required for the time periods Hour, Minute and Second. I can't think of any situation where seconds would actually be needed, but might as well have the complete set.
• Update the Day period class to extend the \Iterator interface and provides each hour of the day upon iteration. Iterating over hours gives minutes and minutes gives seconds, as would be expected.
• Update the Calendar and Factory classes to add new createPeriod() helper methods. They are also now defined in the FactoryInterface.

Strict Dates

• Create new option called strict_dates (default: false).
• Update isValid() static methods, return false if the supplied \DateTime object is not at the very beginning of the date/time period.
• If strict_dates is true, then a NotAPeriod exception is thrown from the constructor of the chosen period class when isValid() returns false.
• If strict_dates is false, then do not validate the \DateTime object; automatically set the begin date to the beginning of the date/time period.
• Create helper methods getStrictDates() and setStrictDates() in the Calendar and Factory classes (has not been added to the FactoryInterface).

Strict Dates: Example

<?php

$date = new \DateTime('2014-05-11 17:23:49');
$factory = new \CalendR\Calendar;

$factory->setStrictDates(true);
$month = new \CalendR\Period\Month($date, $factory);
// A NotAMonth exception will be thrown.

$factory->setStrictDates(false);
$month = new \CalendR\Period\Month($date, $factory);
// The date returned from $month->getBegin() has been set to '2014-05-01 00:00:00'.

Unit Tests

All changes have 100% code coverage with unit tests which pass on Travis CI.

Single it is sometimes necessary to work with custom date/time ranges, I've added the Range class. Possibly, this could even be used as a base class for the other period classes, but I didn't include that in this pull request as it's definitely another change.

This PR modifies the present alternate-periods branch to allow use of alternate Factory that implements a new FactoryInterface, rather than having to extend CalendR\Period\Factory as it would with the current. It also moves the alternate period creation logic used by Calendar.php back to Calendar.php from Period/Factory.php, to simplify the Factory Interface. FactoryTest is modified to reflect these changes.

I have not changed the phpdoc "@return" statements in Factory and elsewhere that assume that FactoryInterface methods return objects that extend CalendR\Period\ objects. I note that the AlternatePeriodsTest only verifies that the code will handle alternate period objects that extend those objects.

It might be useful to permit alternate period objects that implement PeriodInterface (or, better, an Interface specific to Year, Month, Week, Day and Range objects) without having to extend the existing objects.

If AlternatePeriodsTest reflects what you consider to be the required behavior of any Year, Month, Week, Day or Range object, then I could work out the interfaces from that.

When calling $factory->setFirstWeekday() depending on current month first day, the class can generate an error.

For example, trying to set first week day as Thursday on May 2013, via: $factory->setFirstWeekday(4)

generates this: Fatal error: Uncaught exception 'Exception' with message 'DateInterval::__construct() [dateinterval.--construct]: Unknown or bad format (P-1D)' in ../vendor/yohang/calendr/src/CalendR/Period/Month.php:84

It's the second time I'm using Calendr for two different projects and I still get this error :

The first time I used Calendr I had a PHP 5.4 server so I could use traits. My repository was declared as your first example code. To avoid the above error, I just added implements ProviderInterface to the EventRepository declaration and it was done.

Now my server is under PHP 5.3 so I'm using the second way provided on the doc. But, using this second way doesn't provides all the methods required by ProviderInterface and, at this point, I'm stuck…

        $factory = new \CalendR\Calendar;
        $month = $factory->getMonth(2020, 6);
        $events = $factory->getEvents($month);

CalendR\Event\Exception\NoProviderFound: in file /home/wwwroot/akstest.gewu.pro/tooth/vendor/yohang/calendr/src/CalendR/Event/Manager.php on line 68

Hi all!

I'm working with this library for a while (It works like a charm BTW), and I really missing what I think is a good new feature.

The default Event model, does not have the possibility to hold a "data" (Where data is whatever you need, it could be an object, an array or a primitive), and you always have to extend default Entity to include your custom data.

While i think this is good for advanced use cases, i think for simple use cases, having a "bag" where store whatever you need (a title, a status, or even an array with more complex data) without having to extend the default model would be perfect.

I don't know what you think, if you agree I can work on a pull request.

Thanks you for your work

Is this app still working with php 7 and Laravel 5.8?

Because non of the site's bolierplate code is working.

I cannot biuld the calendar, it only renders the day names, Mon to Fri repeteadly.

thanks.

Calendar class uses PeriodInterface as return type for getYear, getMonth, getWeek. Such method should return, respectively, Year, Month, Week, that are implementing \Iterator. With the current code, a call to foreach (new Calendar)->getMonth() is marked as invalid by phpstorm ("Can not iterate PeriodInterface").