It took me slightly over a week to do, but the DOMi refactoring is complete and DOMi 1.1 is now released. With this released, I can shift my focus back to Septuro and to the form plugin. I will also be doing some work on putting hooks into Septuro that plugins can make great use of to extend Septuro functionality.
More importantly than that, however, is that Septuro is using DOMi 1.1 at it’s core. Fortunately for me, Septuro was already adjusting DOMi’s output in ways that mirrored how DOMi 1.1 would be built. Septuro was manually setting the header type and using the DOMi::RENDER_STORE flag to store the output, rather than echo straight to screen. Since DOMi 1.1 is built with both of those things in mind, the only change I had to make was remove the DOMi::RENDER_STORE flags being passed to the render function, since that flag no longer exists.
I have yet to do some benchmarking on Septuro to find out the exact change in speed, but it will probably be fairly significant. The DOMi benchmark indicates a speed increase of 33-50%, depending on the particular script’s usage of objects or arrays. Since DOMi is at the heart of Septuro, a 33-50% speed increase on DOMi should provide equally significant speed boosts to Septuro. Combine this with possible memcaching plugins, and a Septuro run site could be lightning fast under optimal conditions.
With the DOMi 1.1 refactoring now complete, I’m excited to get back into Septuro work. I really want to see the form plugin and hooks get completed. I plan to take a good hard look at how Wordpress is doing the hooks for plugins, because that system is a really well executed one. I see no reason a similar system can’t be used within Septuro, and as a huge open source advocate, I am all about reusing code to avoid reinventing the wheel. Of course, as an open source fanatic, I’ll be sure to take any improvements I make on the Wordpress hook system and try to get in contact with Wordpress developers to let them decide if those changes are right for their project.
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.
Last night, I was up quite late due to the joys of 5 Hour Energy Drink (which is a rant for another time – I was tired as hell, but couldn’t sleep..) and I got to thinking about XSS – cross site scripting, which is a pretty nasty form of hacking. It relies on the fact that most people use cookies to remain logged into certain sites, and AJAX scripts to make requests in the background. For instance, if I set up an AJAX call here at septuro.com that pulled some page like ‘http://facebook.com/delete_account.php?confirm=yes’ and that URL would delete the account of the logged in user, and assume you had already confirmed, then anyone who came to septuro.com would have their facebook account deleted. Even though that attack was carried out by septuro.com, it was technically your browser (and your cookies) that made the request to facebook.com.
Of coure, that example is a pretty straightforward (and totally made up) example of XSS, but the concept is there. While thinking about this, I realized that the way Septuro loads all of its post data, we could set a filtration on XSS (and SQL injection!) right at the core of the system. When Septuro begins to do its thing, it loads all post, get, cookie and session data into a parameters list, which any module can access through a static method in the controller. If the module could always be assured that this data was sanitized at the core, then every module and plugin maker can feel safe implicitly trusting data provided by the controller.
All it would take is some sanitizing functions in the core that filter out XSS and SQL injection attempts at the root level. Combine this with some hooks for plugins to latch onto – for instance an ‘intrusion_detection’ hook, and a plugin can be fairly easily whipped up that uses the ‘intrusion_detection’ hook and the ‘page_request’ hook to add hackers to a black list… although getting the hooks written in is a totally separate matter that still needs some work.
This is like how Linux prevents administrative action at the core and requires a sudo user password. Any program that needs administrative rights can feel safe that the core system made sure that the action has been cleared and is safe. That system kept Linux very secure, and preventing any attack based on get, post, cookie or session right at the core will make Septuro equally secure.
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.
Septuro will be the premiere php framework in the near future. Septuro is using Object oriented programing with heavy reliance on abstraction and modularization. The other open source languages that are uses are html, XSL, XSLT, Jquery, javascript, css, and mysql. We have tried to make it so that you can change out any of these languages without too much trouble. We keep all the languages separated, “keep your html out of my php, I say.” Septuro will make validation changes much easier on the developer by letting the developer change a rule for a validation in the datatemplate and have it changed in the client side Jquery validation and in the server side validation for all properties that are using that same datatemplate. Datatemplates can be for numbers, called numbertemplate. To go further with the abstraction we will be able to extend the numbertemplate into a timestamptemplate by validating that the number is 10 characters long. This way if a property calls for a timestamptemplate it is validating that the property is a number and also is 10 characters long.
Was able to have the skin grab the navigation from the XML for the modules and put them in the left navigation. The skins navigation itself is kept at the top of the page.
I was able to have the application builder and mocxs builder pages(modules) have their own navigation objects. With these navigation objects I was able to change the navigation for the module whenever a new instance of the module is created is is automatically added to the navigation for the module itself.
Worked on having the three pages of Sepruro Builder, application Builder and mocxs Builder in CMS style, meaning that the content on the page can be managed through a admin system. The content and the title for these pages are stored in the database.
In the Septuro Builder navigation there are links to the modules of septurobuilder, appbuilder and mocxsbuilder. Clicking these link are changing the modules perfectly through html calls. Next milestone will be to change the modules through ajax calls without changing the skin itself. One of the specifications of Septuro is that it works with or without javascript.
Worked on the navigation for Septuro Builder using the navigation plug-in I created a while back and it worked beautifully. The Navigation plug-in is object oriented and is created in the skin module. The navigation plug-in’s xsl in correlation with the skins xsl automatically created the navigation buttons in the location and in the order that the skin module asked for. I am very happy with the navigation plug-in.
