PHP 5.2, late static binding, get_called_class() and $self = new self()

July 29th, 2009 visual77 8 comments

Early on in Septuro’s development, well prior to the name being adopted, I had a tough challenge dealing with the dataTemplates. Chris Webb, one of the Septuro founders, was helping me with this particular issue. In the abstract dataTemplate, we wanted to set up a factory method make() that just pumped out an instance of the class that was called. The issue that we ran into involved late static binding.

class abstract_dataTemplate {
    static function make() {
        return new self();
    }
}
class stringTemplate extends abstract_dataTemplate {

}
stringTemplate::make();

In this example, we called stringTemplate::make(), but since make() is defined within abstract_dataTemplate, the function will always return an instance of abstract_dataTemplate. We found out that in PHP 5.3, late static binding will be better supported and come with a function get_called_class() that will return the name of the called class, rather than the current class. Unfortunately, we run PHP 5.2 on our servers and are unable to use this function. I considered using debug_backtrace(), file() and preg_match() to mimic the functionality, but this won’t work if there is more than 1 instance per line of a late static bind call.

I looked at php.net to see if anyone else found a good solution, but everyone seemed to be stopped at the same point I was. Then I realized I could use static class properties to keep a count of how many times a match has already been found on the current line. This would let me support multiple calls per line without issue – with each call returning the exact class that called it. So I took a function listed in the php.net comments and modified it up to make use of this static class.

if(!function_exists('get_called_class')) {
    class class_tools {
        static $i = 0;
        static $fl = null;

        static function get_called_class() {
            $bt = debug_backtrace();

            if(self::$fl == $bt[2]['file'].$bt[2]['line']) {
                self::$i++;
            } else {
                self::$i = 0;
                self::$fl = $bt[2]['file'].$bt[2]['line'];
            }

            $lines = file($bt[2]['file']);

            preg_match_all('
                /([a-zA-Z0-9\_]+)::'.$bt[2]['function'].'/',
                $lines[$bt[2]['line']-1],
                $matches
            );

            return $matches[1][self::$i];
        }
    }

    function get_called_class() {
        return class_tools::get_called_class();
    }
}

We now have perfect support of get_called_class() in PHP 5.2, and we can use the factory method make() inside the abstract dataTemplate, rather than in all of the derived templates.

Categories: Uncategorized Tags:

Septuro now uses DOMi 1.1

July 15th, 2009 visual77 No comments

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.

Categories: Septuro Tags:

The DOMi refactoring is nearing completion

July 14th, 2009 visual77 No comments

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.

Categories: Septuro Tags: ,

Intrusion prevention will be built into Septuro core

July 9th, 2009 visual77 No comments

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.

Categories: Septuro Tags: ,

Well… looks like the core of Septuro needs to be overhauled

July 8th, 2009 visual77 No comments

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.

Categories: Septuro Tags:

Septuro is the future “PHP framework”

July 6th, 2009 devphillipbrown No comments

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.

Categories: Septuro Tags:

Able to have the skin for Septuro Builder hold the navigation for the modules

July 6th, 2009 devphillipbrown No comments

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.

Categories: Septuro Tags:

Modules able to have their own navigation objects

July 5th, 2009 devphillipbrown No comments

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.

Categories: Septuro Tags:

Work done on Septuro Builder over the 4th of july weekend

July 5th, 2009 devphillipbrown No comments

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.

Categories: Septuro Tags:

Hit milestone of being able to change modules through the navigation

July 1st, 2009 devphillipbrown No comments

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.

Categories: Septuro Tags: