Flattery gets you everywhere

I recieved a very nice email, enquiring about some of my code hosted on my dev server. For those not in the know, I try and keep my libraries in
http://devel.akbkhome.com/svn/index.php/akpear/

This includes alot of my non-pear submitted code, Why not submit it to PEAR, you may ask.

• Maintainance - until the bugs and feature requests calm down on my existing packages, I'm already stretched quite far.
  
• Standards - PEAR standards are very strict (for good reason), but For some of the code, which I use once, adding full documentation is often not within the budget.
• Proof of Concept - eg. DWG_Parser, which could be improved to solve a bigger issue. But I've not got the time/budget to do that, so it lives as a proof of concept, and a starting point if someone wants to use it.
  

Some of the highlights include

• HTML_FlexyFramework - url to object loader and mapper
  
• Config_Singleton - 1/2 finished generic Config Store.
• DWG_Parser - read Autocad Dwg files (extracts the icon only)
• Gtk_ValidateManager - really a HTML form validation framework (interface to build validation rules, and runtime code to apply them to HTML pages.)
• HTML_DataObject - browse and edit code for automating browsing of databases and updating them. (This is about the 3rd effort at this, and it's still got serious issues. - but it does work!)
• SpreadSheet_Generic - a tool that at present, can load a Gnumeric file, and write an XLS file, with templating and block replacement abilities.
• XML_SvgToPdf - takes SVG (from things like sodipodi, writes PDF's - with facilities for templating)
  
• Backup_DVD - a nice routine to automate backing up of data

Along with this, a few projects I've worked on , the clients have allow to code to be open sourced, These tend to be highly specialized projects, so that making a big fanfare of their existance is not really that usefull. However they do provide a good illustration of some of the PEAR classes.

Interestingly if you look at the code size for each of the applications, the size of the library folder (eg. pear) is at least 3 times larger than the source code! - pretty good code reuse.

The two key Projects that are available are:

Hebe
http://devel.akbkhome.com/svn/index.php/hebehaven2/
A Yacht club Membership management, billing application, It illustrates alot of the code above in action. I wrote this in 2003, and still make minor updates, but the project is paid for and pretty much done.

Since this project was done, I've stopped using certain features of the design.

• The default entry page class in Hebe is Hebe/index.php (Hebe_index)
• In later projects the base class matches the project name = eg. Hebe in /Hebe.php
• The template folder was in the top level folder eg. /templates
  
• In late projects that was move to the Project folder eg. /Hebe/templates

FlexyShipping
http://devel.akbkhome.com/svn/team.php/flexyshipping5/
This is a Shipping management application in XUL, I did the specification and outsourced it to a team to build. After the majority was completed, I took it back onboard, and have been working with the end user to complete all the features they want.
It is interesting for a number of reasons other than just using XUL (which simply blows away HTML for intranet applications)

On the positive side:

• It meant alot of additions to HTML_Template_Flexy to support XUL.
• There is a very nice library in there for form submiting of XUL interfaces (and some nice tree stuff) common.js
  
• The code design while not perfect enabled the outsource team to work on a simple concept, and ensure that it was maintainable when It went into the feature finalization stage.
• Due to the Intranet nature of the project, almost all the data validation is done client side.. (so in theory we only check if the return values from update/insert where ok on the server side).

On the not so great side

• There where initial problems that the contractor didnt know how to use DataObject correctly (and missed some of the key features, eg. setFrom(), factory()
  
• The file layout (alot of layered directories is an absolute pig to maintain.. ) eg.
• FlexyShipping_Add_Order_Item was in FlexyShipping/Add/Order/item.php
  
• This should have been FlexyShipping_OrderItemAdd,
  most of the generic subclasses should really have ended up in the top level directory, with perhaps only some of the more specialized page classes in a 3rd level folder (like reports perhaps)
• There is a considerable amount of repitition (eg. lots of small classes which do little more that list/get/set )which something like HTML_DataObject solved in Hebe. However I suspect that this is actually clearer than the HTML_DataObject solutions, which eventually become horrifically complex.

Akbkhome
Of course the latest in the line of projects is the akbkhome website, which is trying to make highly modular the whole Framework concept, with some mixed success. which can be seen now via it'self