Introducing Kalfu

Anyone google Kalfu lately? Well, number 5 on that list (currently) is my "little project" Kalfu. First of all, the name is rather, well, meaningless in a way but no more so than most open source projects. I wanted something that DIDN'T go with the phpmysomething naming or even the yet another blah. Instead I started browsing through some mythology lists (I like myths and have done a lot of researching to work on my fanfiction) and found a rather interesting name - Kalfu.

According to Encyclopedia Mythica Kalfu is "The Voodoo spirit of the night and the source of darkness. He is very dangerous. The moon is his symbol." So I get a moon to incorporate into a logo and an unusual name. Perhaps the "dangerous" part isn't the best thing to apply to an open source project - but another definition calls him "powerful" instead - which is the idea I was hoping to convey.

So what is Kalfu? I'd classify it somewhere between a "true framework" and a "php cms" a la php-nuke(blah), mambo et al. Why write another CMS? Ah, the eternal php question. First let me try to explain what I mean to accomplish with Kalfu.

  1. Kalfu is php 5.1+ ONLY - no backporting, no worrying about previous versions. Php 5.1 or you're screwed. This allows extensive use of the new OO stuff. Someone looking at my code jokingly remarked that it looked like javascript - and perhaps in a way it does. If you look at the Kalfu code it's not something you'd see in any previous php project. From overloading to ArrayAccess to interfaces and abstract classes and new php 5 spiffy general functions, all the new stuff gets used (and possibly abused - but hopefully not)
  2. Kalfu is designed to be modular in nature - the base "core" or "system" or "framework" or whatever you want to call it
    1. Manages Modules and Extensions through an admin system which includes automatic updating
    2. Does extremely basic, pluggable user handling
    3. Handles central configuration (a registry)
    4. Figures out which class/method to farm off depending on the url called (front controller)
    5. Provides centralized db abstraction, variable sanitization, and error handling

    What does this mean? It means that you can create whatever kind of "cms" or website you want depending on the modules you decide to install. It will also have a "packaging" system - where you can write an xml file that will download and install a specific set of modules - say a package for supporting an open source project (news, downloads, forums, bugtracker) or perhaps a package for a blog (blog, gallery, gallery extension for the blog) and never have excess bloat from features you don't want or don't need.


  3. LIGHTWEIGHT db abstraction loosely based on the pdo api and tied into an active record wrapper class so you don't have to write queries

  4. Speed - from browser side caching and gzip support to an extensive, pluggable caching interface that can be used for anything - from the registry to db results and anything in between.

  5. Security - from a "home-rolled" session implementation with encryption to a filter class based loosely on the upcoming php filter extension to an output escaping and validation classes - basic "best practices" for php data handling has been built into the system

  6. A templating system that is easy to use without the overhead - using php user streams and filters you can use any kind of templating you want - although the default uses pure php templates (with an optional "security filter" and even "caching filter" for those that need it) - Also a "widgeting" system that allows template authors to modify the look and feel without screwing up forms or similiar items

  7. Hooks at every level of the application - to give module and extension authors very fine grained control over the system

  8. Ajax support for Admin and User areas

  9. Web services for modules - allowing automatic updates, one click installs, and even integrating ssh or ftp for users who have limited web server file writing access

  10. translation/utf8 support

A big fat list, but something I've been playing with since php 4.0 came out (I have an OLD registration on sourceforge to prove it, even some old files in CVS...blah)

I've had people ask me why I don't incorporate more "prewritten" stuff - such as pear classes (not php 5.1 compliant), ezcomponents (maybe I'll use some later but right now I don't like their apis), and other general items. In some cases (mostly javascript side) I AM using "prewritten" libraries - tinymce, a hacked up version of html_ajax from pear, even some prototype and scriptaculous stuff. However, with php I wanted to keep a tight reign on apis so module writers would see a consistent include/naming scheme (via autoload), consistent variable sanitizing and validation, consistent error handling, consistent database access, and finally consistent use of caching. It simply gets too hard to wrap a bunch of third party php libraries - and I'm not even mentioning licensing pain in butt problems - even the javascript I'm using is taking a major hacking to get it to work with the javascript library included with the framework. I'd like to pare down the framework even more by making things like cache drivers, tpl streams, and db drivers things that are downloaded and installed on demand instead of shipping every possible option - the size of the central system is something I'm NOT happy with at the moment. Anyway - I'm still a decent length list away from even an alpha release but you can always view the svn repo and see what's happening.

Comments

Be the first to write a comment!

Post a Reply