Archive

Author Archive

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:

Less sucky theme!

June 25th, 2009 visual77 No comments

So, anyone who saw this site prior to today would notice something – that theme is awful. Well, screw you, I was in a hurry. I chose the old Wordpress default theme over the new one for one reason – the new one didn’t list the author name. Now, I know what you’re thinking, we created Septuro – we know code, I could’ve edited it. Yeah, I could’ve edited the new default theme to show authors, but I was just trying to get this set up on a stable host, since SourceForge’s hosting is pretty crappy. Well, today I updated to the iNove theme, which looks clean enough and shows the author names of each post.

One of these days, I’ll get the theme looking even better, but for now, this theme is acceptable and does what we need it to do. At some point, we’ll have this site running on Septuro, but until that time, this Wordpress blog is good enough for what we are using this site for – to just post on where the project is at.

Speaking of that, the project is still moving smoothly, and we’ve got our development machines working with DOMi and Septuro in such a way that we keep fixing DOMi bugs while doing Septuro work – so we’re now advancing both projects smoothly. The same thing will happen once we get Yeakum started, as it is just an extension of Septuro into a full blown CMS, but I can’t talk about that project too much… yet. Once it gets rolling, you’ll be hearing about it.

Categories: Uncategorized Tags:

I’m trying to figure out how open source copyright is applied

June 5th, 2009 visual77 No comments

I am an extremely rabid fan of open source software, and Phil and I plan to release Septuro as an open source project. However, one hurdle that we are now encountering is not fully knowing how to do the open source copyright to make it complete and enforceable. This is the first open source project that either of us have worked to this extent. We did DOMi last year, but it was a standalone file that doesn’t have anywhere near the complexity that Septuro has.

We originally planned to use the Creative Commons 3.0 BY-SA license, but after a bit of research, I find out that their license is not ideal for software, and is more intended for works of art. I looked a little bit further, and now we are looking at using the GNU GPL license, and figuring out what we need to do to make it apply to Septuro. I have gone ahead and added a notice to each of the core source code files (a lot of the extended objects are pretty minimal and unimportant, so I don’t see the need to put the notice on everything).

If anyone out there could give us some pointers, I would be very appreciative. We want this software to be freely available to everyone. Part of that will be to make sure nobody else can come along and clamp it down, should we not set up our rights properly. This weekend, I’ll be doing some research into open source copyright law, and I’ll hopefully have this sorted out soon, so we can protect Septuro the way we want it to be protected – by protecting it’s free nature and make sure nobody can lock it down.

Categories: Uncategorized Tags:

Folder restructuring is complete!

May 20th, 2009 visual77 No comments

Earlier today, I killed the folder-restructure branch, merged back into trunk, and called it a day. The ‘element’ folder no longer exists, anywhere, and the plugin folder has been readjusted so each plugin is its own folder. When we first did the layout of Septuro, we created an element folder to house all of the PHP, broken down into sub sections like ‘objects’ and ‘modules’. After a few months… we realized we ONLY use objects and modules. So, we decided to do some retooling, eliminate the elements folder, and move objects and modules to the top level.

Now that I am done with this, I will be working on the form plugin. I’m doing this on the trunk, since the current application/plugin set up makes it easy to build new things without interfering with others. The folder restructuring would’ve messed with others quite a bit, so I had to do that on a branch.

This form plugin is going to be really, really cool. I can’t rant and rave about it enough. It’s a great idea that will smooth out form creation, validation and processing into a few simple steps, even supporting multi page forms that require session or cookie data to be stored.

Speaking of sessions, while making this form, I’ll be working on a new session object, alongside the database object and xml object, to store object data in session variables as its system of persistent storage. Like the other object-storage layers, it will handle everything without interfering with the first or third tiers.

I’ll post more on it as it comes along, since this will be a hefty project.

Categories: Septuro Tags:

Restructuring large parts of the folder structure is painful

May 19th, 2009 visual77 No comments

Recently, Phil and I were looking at a new system that he is developing for Septuro – where the autoload cascades across the application, parent applications, plugins and finally onto the system core. This is a really cool system that lets you override existing objects with new objects, or even extend existing modules. It is taking the concept of object oriented programming in a new direction, and applying those concepts to entire file structures.

While working on this, we noticed that the plugin directory wasn’t structured in the ideal way, and while looking at the folder structure, we also finally decided to do what Phil has long suggested – kill the element folder and relocate its contents into an object and module folder. I created a new branch today – folder-restructure – where I will be doing all of this tweaking. This really is a pain, but better to do it now than deal with the pain of it later.

I should have this branch finished and reintegrated into the trunk before the end of the day, and then I can get back onto working on the long awaited form plugin. That plugin is going to be really, really cool. I’m excited to get down into working on it. It takes my previous work on the dataTemplates and abstract objects and puts them in a new light. An object can be converted into a form really easily. Just tell the form what object it is working with, the object already contains information on how to be displayed in a form, plus it’s validation rules, and then give it a callback function to execute on completion – it’ll be sweet.

Categories: Septuro Tags: , ,

Septuro is close, but has a long way to go

April 28th, 2009 visual77 No comments

Last night, I was working on a branch, building the new form module tools. These tools are going to be really powerful and let you whip forms together out of existing objects really easily. They use the object properties as defined in the third tier of each object, and do all of the PHP / jQuery validation setup for you, and since it all runs through a single location, the HTML structure of all forms remains consistent, making CSS framework designs easier.

However, while working on it, I realized that we have a long way to go in terms of error reporting and exception handling. I built a form application specifically to handle this, and could not get it running through the proper skin module. These skin modules are just like regular modules, but contain rules for determining the outermost skin, and it is code that Phil added in over the past week.  I was getting few helpful error messages, and I was never quite able to get a working application.

We’ve got some work to do with those error messages so that developers working on Septuro have a better understanding of what went wrong. I think the first step is to adjust the magic __call method built into DOMi, which is at the core of Septuro. It was built in to silently feed function calls over to DOMDocument, DOMXpath and XSLTProcessor, but if the function doesn’t exist, the error message that is provided is pretty minimal and easily silenced by other code.

Categories: Septuro Tags: