Septuro

I’ve been working for about a week now on a complete refactoring of DOMi, which is the class at the heart of Septuro, and the refactoring is nearing completion. Once it is done, I will release DOMi 1.1 and integrate 1.1 into Septuro. Preliminary tests with DOMi 1.1 and Septuro are giving really good results – almost nothing of Septuro needs to be tweaked to work with this new version of DOMi, but Septuro loads significantly faster now.

The main focus of the refactoring was to slim down all of the bulk that had grown onto DOMi since the original AttachToXml function was written nearly two years ago. Over time, new features were added for sanitizing input, checking doc type, disabling prefixes/xpaths and other things that were deemed to be outside of the original scope of DOMi:

“a merger of DOMDocument, DOMXpath and XSLTProcessor, with extended functionality for converting PHP data types into an XML structure and convert the XML into the desired output format”

Now that DOMi has been retooled and cleaned up, it can be put into the core of Septuro to speed up processing times. This will also fix the bug where the root node was always /septuro/module/module instead of just /septuro/module – a bug caused by glitchy processing of importing DOMDocuments.

I’m really excited about this refactoring, because it also introduces unit testing into DOMi, which is the piece that I am still working on. This is my first go at unit testing, but it is coming along pretty nicely. With good unit testing in place, we can ensure that the core of Septuro, the DOMi object, always remains robust and fully capable. It will be very easy to put Septuro onto DOMi 1.1 – from my early testing, only 2 lines of code needed to be changed to work with the new DOMi structure.

Septuro is a PHP framework built around the DOMi core, and that core needs some housecleaning. DOMi was originally built as a project at work, but was open sourced and is now used at the center of DOMi. A work today, I noticed some extreme inefficencies in DOMi – notably with the AttachToXml() function, which rests at the heart of DOMi.

I did some benchmarking on the corporate intranet and came to the conclusion that the two biggest slowdowns are in DOMi’s AttachToXml() and  Render() functions. The slowdown on Render() is more a sign of inefficient XSL than anything in DOMi. I have wanted to clean up AttachToXml() for some time, and now I’ve been forced to do that. Hopefully, it won’t take me any more than a week or so to rewrite how that function processes and reduce the execution time pretty drastically. The function started off okay, but as time went by, it got more and more gnarly. One of my definite goals is to keep backwards compatibility. I don’t plan on changing the input or output of this function, and just rewrite how it internally processes, but that’s just good object oriented programming practices.

I’m sure this will end up with the release of DOMi 1.1, with the major change simply being a drastic speed increase. Once DOMi 1.1 is available, it will be put into Septuro immediately, which should cause a noticable increase in Septuro rendering speed, which will also speed up Yeakum, once the CMS is built on the Septuro core. It all goes back to AttachToXml(), however, since Yeakum is built upon Septuro, which is built upon DOMi, which is built upon AttachToXml(). The engine of all of these systems needs a tuneup.