Re: [PHPiCalendar-DEV] Rebooting phpiCalendar

[Jim Hu <ji...@ta...>]

On Dec 3, 2010, at 3:40 PM, Jason Oster wrote:

> 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.

I think there are many good suggestions here, including the core one of moving on to phpicalendar 3.  My only problem with switching to Git/Mercurial and Trac is that I think it's beneficial to maintain a presence on Sourceforge.  But we could at least move to subversion while staying on Sourceforge.

I also think that despite my intention to get back to phpicalendar, the data from the past couple of years indicate that I'm not putting in the time needed for the project.

Jim



> 
> ------------------------------------------------------------------------------
> Oracle to DB2 Conversion Guide: New IBM DB2 features make compatibility easy. 
> Learn about native support for PL/SQL, new data types, scalar functions, 
> improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, 
> best practices and more - all designed to run applications on both DB2 and 
> Oracle platforms. http://p.sf.net/sfu/oracle-sfdev2dev
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel

=====================================
Jim Hu
Associate Professor
Dept. of Biochemistry and Biophysics
2128 TAMU
Texas A&M Univ.
College Station, TX 77843-2128
979-862-4054