deni-zen / qcal Goto Github PK

Refactor Property class according to notes in your notebook.

To keep code consistent and easy-to-read, write a programming style guide for the library that specifies how files are named, namespaced, how code is written (indentation, capitalization, naming conventions, etc.), commented, and any other things you can think of to make consistent.

qCal\Value\Date should use qCal\DateTime\Date object. Once qCal\DateTime\Date class is written, refactor this class.

Implement TimeZone support for DateTime class. As of now, qCal\DateTime supports time zones only insofar as PHP's DateTime class does. In order for it to support time zones in qCal, it has to be able to gather time zone information from the iCalendar file (or other source) being worked with and store it in a registry so that when time zones are referenced (by TZID) elsewhere in the file, qCal knows where to look for the associated time zone information.

DTSTAMP property must have a datetime value in UTC time. Throw exception otherwise.

See if qCal\Value\Uri should have any more methods and implement them. It doesn't do anything because technically it just deals with a string. But the string is a URI. So is there anything it should be doing to work with a URI?

I have littered the code with @todo comments that all need to be converted to GitHub issues.

Look through the RFC and make sure that the only component ACTION is used on is VALARM. As of now, an exception will be thrown if it is set on any other component.

Look at the conformance definition for VTIMEZONE and make sure all the time zone properties' conformance rules are right. Look at the format definition for VTIMEZONE and it should tell you exactly which properties are allowed on VTIMEZONE, STANDARD and DAYLIGHT. Implement.

Like many other properties, the RFC is not very clear about which components it is allowed to be specified on or other conformance rules. Make sure it is correctly conformance-checked.

qCal\Parse\Lexer::getTypeString($int) should throw exception if $int is not found in its $resolve array.

qCal\Parse\Reader\FileReader throws a generic exception if passed a file that doesn't exist. Implement a custom exception here.

I'm thinking about renaming all the component classes. VEvent would become Event, VCalendar would become Calendar, etc. If I do this, I would need to also put Standard and DayLight into the qCal\Element\Component\TimeZone namespace. I think this would be a lot cleaner and less awkward.

Refactor Parameter class according to notebook outline

Make sure qCal\Parse\Lexer::manageEOLChars() handles all possible newline characters correctly.

The COMPLETED property, according to the RFC, must have a UTC time as its value. Throw an exception if its value is not in UTC.

The conformance classes need to support a configuration array or object to toggle support for various features and settings. For instance, RFC 5545 has deprecated support for the PROCEDURE value of the ACTION property. I would like to still make it possible to support that value by enabling it in a configuration setting.

Property::__toString() returns only the value as a string. It needs to return its name and parameters too. Returning it as a string according to the iCalendar format though, will be code duplication though because that code belongs in the renderer classes. Figure out how you want to handle this and implement it.

Make sure SEQUENCE property's conformance rules are right.

The RFC mentions the value of PRODID being a globally unique identifier such as "FPI", defined by ISO 9070. I could not find much on this standard, but typing ISO 9070 did return this page in google:
https://tools.ietf.org/id/draft-ietf-calsch-icalfpi-00.txt

In any case, PRODID's value is supposed to be a globally unique identifier. Figure out precisely what this means. I know what a globally unique identifier is, but are there specific guidelines or conventions on creating one?

Like many other recurrence-related properties, I am not sure if I have conformance right on the RECURRENCE-ID property. Just make sure they are right.

The FREEBUSY property must have its period value set in UTC time.

qCal\Element::getQCal() returns the qCal wrapper object, regardless of which qCal\Element it is called from. Write thorough unit tests for this method.

Write a method to generate unique IDs for use on UID property. Probably qCal::generateUID().

Just as with all the other recurrence properties, the RFC is ambiguous. Make sure it has the correct $allowedComponents.

Component::generate() is throwing an UndefinedComponentException. Make sure this is the right one.

The CREATED property, according to the RFC, must have a UTC time as its value. Throw an exception if its value is not in UTC.

Write unit tests for all Property methods

Change Component::attach() to Component::addChild().

qCal\Parse\Reader\FileReader uses error suppression on fopen. Handle this properly.

The TRANSP property's conformance definition says it "can be specified once". Many of the other properties that can only be specified once just say "can be specified for X component". Why the difference in wording? Is it just an oversight? Just look into it.

VAlarm has different required properties depending on the value of its ACTION property. Need to specify which ACTION values result in which required properties in the exception message.

Write unit tests for component class methods

Because qCal\DateTime currently has no support for time zones, qCal\DateTime\Period started calculating its conversion to a qCal\DateTime\Duration incorrectly when I switched from working from my iMac to working from my MacBook. For right now, just so that I can continue working on the lib, I have temporarily fixed the problem by setting the timezone to UTC. This doesn't actually fix anything, it just hides the problem. But it will work for now.

To fix the problem, implement support for time zones in qCal\DateTime, as referenced in issue #4 and then remove the hard-coding of UTC in qCal\DateTime\Period.

This method may not need refactoring. It has several conditionals and I think what really is the issue is the component interface's property accessors. Because properties can be set mutliple times on a component, the property accessors get ugly. If this method can be cleaned up, clean it up.

The VALARM conformance class throws an exception if REPEAT value is set to a value greater than one and the DURATION property is set. Make sure this is the correct behavior.

Double check the RFC to be sure all the conformance rules for RDATE are in place.

qCal\DateTime\Duration::setDuration() says a whole bunch of crap in its definition that it doesn't actually do. Implement all the stuff it says in its definition or change the definition.

The ATTENDEE property doesn't explicitly specify which components it is allowed to be defined on. Make sure that it specifies all allowed components.

I had, at one point, added the RFC descriptions of each property to their respective classes, but somehow they got reverted to versions without the RFC descriptions. Go back to each property and add the description from the RFC.

Should qCal\Property\MultiValue::addValue() support arrays? It probably should.

The CalScale property specifies which calendar scale the calendar uses. So I'm assuming this means it has to support scales like Julian. Look into it and find out if you have to go through that nightmare.

Make sure REQUEST-STATUS property's conformance rules are right.

The DESCRIPTION property, according to the RFC, must have a UTC time as its value. Throw an exception if its value is not in UTC.

Write tests for all Parameter's methods

The exceptions in this library are extremely inconsistent and nonsensical. After the style guide is written (see #8), rewrite/rename exceptions according to the style guide.

There are unnecessary methods in qCal\Parse\Lexer. Why is there both qCal\Parse\Lexer::eatWhitespace() and qCal\Parse\Lexer::eatSpaceChars()? When I wrote this I was looking at PHP Objects, Patterns and Practice and trying to just get the lexer to work right. I probably added several unnecessary methods. Refactor.

STATUS property's conformance rules need to be checked.

Remove any unnecessary methods on Component class. There is a few pages in my notebook that outline all the Component methods and what their names should be. Refactor according to those pages.