[PHPiCalendar-DEV] Rebooting phpiCalendar

[Jason O. <par...@ko...>]

This may not be the most popular mailing list ever, but I need to throw 
the idea out there: It's time to reboot phpiCalendar.

phpiCalendar 3 was in the planning stages for a while, but fell out of 
development while the 2.x series saw most of the work (in the form of 
maintenance).  At this point, maintaining the 2.x branch is getting very 
difficult.  There's a lot of weird code in it, no standard code style, a 
custom template engine (which would require significant PHP transplants 
to actually re-style some things, like the week view), ...

As far as I can tell, phpiCalendar was actively maintained by the 
original developers, where it saw a great deal of development, but also 
received its fair share of hacks and workarounds to get it to where it 
is today.

The size of the codebase is quite significant, even for an ICS parser. 
An ideal parser could probably be written in about half as many lines, 
and be more robust and accurate.

I really liked Jim Hu's idea when he started on phpiCalendar 3: an 
object-oriented API for the parser, which can be made reusable in other 
projects.  (Or at least, that's what I was able to infer from the random 
forum and list posts.)

So I had a brief (very brief) look at the phpicalendar3 repo at SF, and 
the code looks nice.  The code looks *really nice*, but there's a lot 
missing, and a lot of TODOs sprinkled throughout.

I would like to make a proposal, and I'll wait another year if I have 
to, until I get some feedback on the thought.  But it would be a good 
time to drop support for the 2.x branch, and focus on 3.x.  I believe 
it's also important to move from CVS to Mercurial or Git.  (I have 
practical experience with Mercurial, but I am very interested in using Git!)

And not only replacing the SCM, but also the issue tracker.  SF's 
default issue tracker is ugly, hard to navigate, and doesn't provide any 
information beyond what users think is broke, and what developers think 
is fixed.  My suggestion for a replacement is Trac.

*AND THEN* there's the issue of actually writing some code to make 
phpiCalendar 3 happen.  I'm considering hacking on the current base 
repo, rather than rebooting even that.  There may be some big 
architectural changes that I want to make, though.  The most obvious 
example: I don't believe every feature of the ICAL spec needs its own 
class.  That sounds like OOPs-overkill, to me.  Jeff Atwood's lovely 
(and aptly named!) Coding Horror blog covers the problem well enough 
without reiteration:

http://www.codinghorror.com/blog/2007/03/your-code-oop-or-poo.html

But it's probably a safe bet that the whole thing won't necessarily be 
scrapped.

Next, it needs a user interface.  The 2.x branch is actually quite 
pretty.  You'd never know how terrible the PHP is, just by looking at 
one of the rendered calendars!  So yeah, that came as quite a shock when 
I dived in for my first bug fix.  This interface needs to be there, 
ported in some form.

The CSS (and the HTML) will see some serious overhaul, for certain. 
CSS3 is widely supported, itself supporting features like drop-shadows, 
which the current templates simulate using GIF images.  The template 
engine needs some TLC, as well.  My suggestion at this time is using a 
very simple template engine called phpSavant:

http://phpsavant.com/

It's a template engine without its own special language syntax. 
Instead, you just use PHP when you need to iterate over data (page 
content), rather than the clunky, proprietary macro-things provided by 
engines like Smarty.

This means that pure template designers are pretty much screwed when 
they don't know PHP, but that problem can be eradicated with

<?php require_once('draw_week.php'); ?>

at the top, and

<?php draw_week_header(); ?>

wherever the template wants to place the HTML for the week header, etc. 
  It still presents a Model-View-Controller level of separation.


TL;DR:

1) Scrap phpiCalendar 2.x.
2) Pick up work on phpiCalendar 3.x. (Follow coding and style conventions!)
3) Move the code to Git or Mercurial.
4) Move the issue tracker to Trac.
5) Reimplement the user interface in CSS3 using a simple template engine 
like phpSavant.