mikhail panchenko / blog

Basics

All code for ked_core and my other projects can now be found here.

Slight change in nomenclature (aka stuff I hate) – the package that contains the framework itself will now be called ked_core, to accomodate future projects like ked_pdo and ked_auth that will play nicely with the framework. Those will have to wait until I un-dumbass myself by doing some more reading. And just completely stop giving a fuck about school and dedicate all my time to hacking.

Some General Thoughts

I’ve decided I can’t call it an MVC framework – because I don’t believe in models in the way Rails does. I don’t think an application has to be based around a model. Just because Rails has a built in implementation is not a good reason, to me, to use one. I have legitimately written an application that was very useful, but used NO database whatsoever. Anyone is free to use a 3rd party model implementation or write their own, but ked won’t require one by default.

Change in Goals/Scope

So as I was fucking around with the code, I decided to stop and revisit my goal: building a framework that can follow a site as it grows from something completely tiny hosted on something like Dreamhost to a massively scaled site with its own farm. For that two things are needed: leanness (least possible number of required operations and disk reads/writes per page load) and maintainability. The overall goal is now to be able to just download a ked skeleton to any host with PHP5 (I’m using my 5.95/mo Dreamhost account as a benchmark; if it works there but not on your host, kill yourself), then be able to grow it from there and move it to any other host near seamlessly. The changes to the core are as follows:

• ked will now only run through a single index.php file, which will then load all the appropriate files for all the controllers. It ends up actually being 1 fewer include per page, thus one fewer fs operation. I realize that isn’t a big deal if APC is involved with opcode caching, but remember – every little bit counts.
  • no apache configuration needed beyond RewriteRules in .htaccess.
• ked now also supports grouping controllers/views into folders. Naming your controller admin_mainController adn placing it into /ked_app_root/inc/controllers/admin/main.php will work. Your views can then go into /ked_smarty_dir/templates/admin/main/viewName.tpl.
• Similar functionality for layouts.
• ked_core is still probably ~100 lines of actual code. Everything uses single quotes and only basic string operations – no regular expressions except in my print_r wrapper dump(). There are minimal advanced functions used – one instance of reflection, I believe.

My general stance on what ked will/won’t do also changes, so it will INDEED now wipe your ass for you for the sake of maintainability.

• ked will generate controller/view skeletons for you via a webbased control panel (pending user permission limitations – to be investigated)
  • if PEAR_DocBlockGenerator is installed, it will use that to generate docblocks for those skeletons
• ked will support phpUnit integration (but obviously won’t require it) as well as svn hooks to automatically run the unit testing and append test failure notices to the -m msg, citing who committed the failing code.

To Be Done:

• the basic ked_admin package for skeleton generation/management (which will, btw, use ked_core )
• rewriting mihasya.com to use ked_core to demonstrate TEH POWAERS, hence its presence in my subversion tree – you’ll be able to compare the original tree with the ked’d tree.
• investigating integration with PEAR_DocBlockGenerator, phpDoc, phpUnit, Subversion, and my taint.

This entry was posted on Saturday, March 22nd, 2008 at 10:16 pm and is filed under framework, ked, mvc, php, tech. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.