tinycrud, a php framework based on W3C XML technologies
man on wheel tinycrud aims to build the lifecycle objects for creating, reading, updating and deleting (aka: CRUD) standard entities; in our case represented by mysql tables. The resulting code has no tight couplings to any other class libraries in order to run, which creates a very slim footprint during execution time. tinycrud is designed to distill code, not hold it hostage forever within it's tight framework grasp. And best of all, I don't care if you use it!

Make everything as simple as possible, but not simpler. The philosophy is simple: "get thee to XML as soon as possible". If you want to overlay an MVC metaphor, it's XML that is our sole data model format. Views are XSL, and our front controller uses reflective techniques to remain compact, yet customizable.
To quote Albert Einstein, "Make everything as simple as possible, but not simpler.".
How it works
  1. CREATE TABLE `calllog` (
    `calllogid` int(11) unsigned NOT NULL auto_increment,
    `phonenumber` varchar(20) NOT NULL,
    `melissadata` text,
    `notes` text,
    `calltime` datetime NOT NULL,
    `prospect` enum('0','1') default '0',
    `lastmodified` timestamp NOT NULL,
    PRIMARY KEY (`calllogid`),
    UNIQUE KEY `calllogid` (`calllogid`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8
    mysql tables are reverse-engineered into XSD documents. Type-binding occurs between mysql data types and intrinsic XSD types. Custom XSD types exist to represent specific mysql data types, eg: NULL or positive integer. You as the implementor can invent your own XSD types. A good example is a regular-expression for an email type. Instead of thinking in the traditional 'create-table' mindset when you architect new entities, you have to think of the XSD as the more detailed and authoratative source for the schema of an entity. Metadata about visibility, data types, and serialization is tucked away in the <xsd:appinfo> subtree, as defined by the XSD standard. See Extending Schema.
  2. XSLT Book Now that we have an XSD containing all of our database DDL and meta-data about php attributes, we can transform this with XSL into several goodies.
    • First, we have an XSL file called scheminator.xsl which builds a boiler plate php class, and all of the necessary mysql 5.x stored procedures. It produces a singleton, and there is no plan to build composite entity strategies, foreign key identification, or any other type of linking magic; you should code this part. Also, you code list handlers by writing custom SQL which is converted to XML and tucked neatly within the enclosing DOM context.
    • Secondly, the XSD is transformed into the default form, or forminator.xsl, and uses the intrinsic and custom types defined in the XSD to insure type safety onchange of any element on the client-side. In other words before a change is dispatched via AJAX, the field is checked against a dynamically generated Javascript sanity checker.
  3. Default front controller A default "front controller" exists to deliver forminator (remember our default form) and to catch the response to field updates which are dispached as AJAX calls. So forminator is a data-bound form that sends update events to our default front-controller. The front controller maps form field names to class members, and calls the save() method. Imagine the front controller's job is to capture the HTTP request, access the noun and verb associated, procure the proper class(es), bind the HTTP request collection to object members, and call save. In more complex interactions, it may be procuring one or more objects and linking them together, or calling cascading deletes.
Handling change, mindless and bug-resistant revisions with vimdiff
Here is the lifecycle of the build process (special thanks to Clint Byrum on showing me vimdiff!):
  • ./make.sh xsd
    Runs through application.xml and explodes every mysql table into a respective XSD file in /xsd/templates/
    Then you vimdiff /xsd/Class.xsd /xsd/templates/Class.xsd and visually bring together the changes that belong. Because every layer is customizable, you don't want to auto-diff the files (usually).
  • ./make.sh classes
    Runs through application.xml and transforms every XSD document in /xsd/ to a standard php class file in /lib/classes/templates/
    Then you vimdiff /lib/classes/Class.php /lib/classes/templates/Class.php and visually bring together the differences.
  • ./make.sh procs
    This calls each class file in /lib/classes/Class.php?action=procs which drops and re-builds all stored procedures for the given object. They are stored within the respective class so that they can be versioned (subversion in our case). There are no compatability nightmares when you roll back, because the stored procedures match the class definition.
  • ./make.sh validate (optional)
    Looks in application.xml for classes that require validation. This will load the class with the given test key, call toXML() and then check it against it's XSD for validity. Imagine this process takes us full circle: we are retreiving a record, serializing it toXML, then validating it against the very same schema that created the class in the first place. This works very well in development to find out when the schema does not match up against the data in the database. make.sh validate helps when customizing your own data types to flush out errors in the XSD customization process, and you can write mini programs to rip through an entire table for higher-level data integrity checks, eg: NULL or valid email.

diffing revisions with vimdiff

So why are you doing this? Why not use (XYZ)?
Does this project sound like other projects? Rails, AppFuse? Well nothing is invented in a vacuum, and this idea is most-certainly not rocket science. What is important is the implementation of many other language-independant standards in this project.

The inspiration for this project was that I could not find anything based on primarily XML technologies that did the job in php (NOTE: since then others have popped up see here). I had other friends and colleagues using XSD at the time, and it wasn't a far stretch to use is as the basis for entity declaration. Furthermore, as I studied other frameworks in Java et. al., I found that they were shrouded in complexity and constant revisions that broke compatibility (many have since settled down, and I have alot of respect for those). I just want to write code (and as little as possible), not run on the treadmill updating and testing the landscape every time a new version of the framework is released. (end rant)

Yes, I love Java (on the client... see: my Java XML GUI widget library), but over time I have gravitated towards php on the server. The idea of this project is that ~65% of your code will be 100% portable, due to the standardization of the dependent technologies: XML, XSL, XSD, XPath and DOM. If you wanted to, you could rewrite your own scheminator that produces Java or perl classes, and still employ the entire view (xsl) layer and entity declaration aspect (xsd) without modification. Therefore I like to say that the framework is resiliant to language changes.
BSD License
Valid XHTML 1.1