Back to the code...

Well, I'm back to coding again - lucky me. I've been working on kalfu again and have made some progress. Probably the biggest thing were some "left brain induced drawing moments" where I actually sat down and mapped some things out. Also I worked on getting the data filter working the way I wanted it to - simple and efficient yet similiar to the upcoming 'Php input filter" extension.

The php filter extension (see for more details) is still experimental and does some things I don't exactly agree with. For example it has a series of sanitizing filters (makes sense) but also a series of "logical" filters that return false when you try to grab data from post/get/server/whatever - I don't know about you but I use a seperate validation class for things like that. If I simply got false for everything I can't tell the person "your email address is correct" - my validator would instead assume that the idiot left the email field blank - which would mean an upset user and lots of people using the "RAW" filter just so they can validate things properly (ick)

My filter class stays away from any validation - it does just what it says - it filters. If you ask for an integer - it will cast whatever the heck it finds as an integer. If you ask for a get string with only alphanumeric characters (using the REGEX filter) - well that's what you'll get. Validation belongs in the validation class (and that's what ctype stuff is for!)

Anyway, grousing aside, the filter class is looking pretty nice. I'm still working on a real version of strip_tags (in otherwords, one that handles both tags and attributes) and I want to add in some kind of output or parsing filter hook (think bbcode or wiki or texturize or any of the other little "formatting" schemes besides straight html/xhml) but most of the functionality is working now.

The other big problem was coming up with an activerecord implementation that works in php - in the original active record "spec" it's supposed to work like this - static implemenations of stuff work on all rows and instantiating the class works on a single row - well that's an interesting idea but a pain in the ass in php. I ended up using some "magic" of my own.

I ended up making two abstract classes for activerecord - one to extend for most things, and an "activerecord collection" abstract class - the trick is although the first one needs to be extended for whatever object you're doing (people, cows, blog posts) the second is "magically" extended if you call the findAll function in the regular activerecord object - the activerecord collection will hold an array containing all the data and through the magic of php5 iterators and overloading will create activerecord objects for each row as needed. It's an interesting trick and shows how even though eval is evil, it can be VERY useful too.

The biggest trade off I had to make was automagic introspection of tables for activerecord objects - although this makes things work very "cool" it also makes things work very...well..."slow". Database calls are usually the biggest bottleneck in a php application and having to add extra calls to get the table structure seems kind of crazy to me. Eventually I'll have a modulecreator module for kalfu (hey, I'm lazy) that will allow auto skeleton creation of activerecord classes either from tables in the database or definitions in an xml file using the kalfu db schema.

Well, right now I'm just combing over the current code in the svn repo and fixing problems with really old apis for error handling and data filtering - also adding in some classes as I go. I started a uml diagram but that gets old real fast - anyone who needs something to do can put all the classes into the diagram for me, it's in svn and just uses good old dia :)


Be the first to write a comment!

Post a Reply