[WIP] Studio: Greeble

[Rob Oplawar]

Hi guys. I'm going to try to semi-regularly post the source code of Greeble as I finish it, up until the alpha release of Greeble when the timer at http://greeble.net expires.

This code is open-source, and is meant to be self-documenting, meaning you can just grab any old source code file out of Greeble and look at it by itself and figure out mostly how it works, no searching around for external documentation or guessing at what an included file or referenced function does.
The comments at first glance appear extremely verbose, to the point of cluttering the code-- it's meant to be viewed in a modern editor, and most modern editors will automatically collapse large comment blocks like that into one line, making the code much more readable.
The @ prefixes on certain lines in the comments indicate the comment line's special meaning to an editor, usually to give it information on a class method to help the programmer when calling said method.
The @access annotations are redundant and I really ought to go ahead and remove those, but they're friggin everywhere. Lol.


First off, the second most useful class I have ever written:
MySQLRow.

Next week: the most useful class I have ever written, MySQLTreeRow!

[Masterz1337]

Sweet Deal.

[SnaFuBAR]

Still want me to try that logo for you, Rob?

[Rob Oplawar]

Yes please.

So, I just added the MySQLRowFactory class yesterday. Before all of that functionality was part of MySQLRow. As a result of this new way of doing things, my classes that extend MySQLRow (about 10 of them) have decreased in size by about 100 lines each.

A sign of huge progress- my framework just got 1000 lines smaller overnight.

MySQLTreeRow on the way, as soon as I work out all the bugs so my unit tests pass.

e: Updated MySQLRow to make it more flexible.

[Advancebo]

Whats a Greeble :V?

[Limited]

Whats a Greeble :V?

His PHP based forums he made from scratch.

Nice rob work, huge count timer, 21 days? :P

[Rob Oplawar]

Ok, still working on MySQLTreeRow.

In the meantime, I've renamed MySQLRow.php to DBRow.php, to reflect the fact that I've now added a layer of abstraction to it, so that the interface can be database independent. Currently I've only implemented it for MySQL and have no plans to implement for any other databases, but it's good to leave your code open to modification.

I've also changed around the code somewhat in anticipation of PHP 5.3.0, which supports late static binding, which will be a huge code-saver for me.

I got rid of the MySQLRowFactory class, bringing that functionality back into MySQLRow, and am just living with the fact that until late static binding is supported I will have about 50 lines of duplicate code per class that extends DBRow, and will have numeruous call_user_funcs in there, in addition to having a slightly wonked out interface.
5.3.0 comes out sometime this quarter, so hopefully I won't have to live with this for long.


I've also finished writing the unit tests for the DBRow class. 23 tests, 145 assertions, all pass. It doesn't provide quite 100% coverage, so in the future I may want to make those tests a bit more thorough just to be sure, but in the meantime it shows that the code is solid for general use.


The coolest part of the MySQLRow class is, in my opinion, its support for SQL JOINs. The interface has two types of joins- tableJoin and classJoin.
Table join works exactly like a normal SQL join, with a couple of restrictions. It performs an inner join from the primary table of the class it belongs to to some other table on the my_index field. This is for relational support, splitting a table into multiple tables to lighten queries when not all columns are necessary.
In the future I plan to remove the restriction to INNER joins on my_index, to be more flexible.
The other join, Class Join, does one better. It can perform LEFT, INNER, or RIGHT join from one DBRow class to another DBRow class. It's hard to describe how it works in the abstract, so have an example instead: Say I have a posts table and a users table in a forum system, and matching Post and User classes. I can left classJoin Post to User on post.author_index = user.my_index, and then when I get post 1 from the database with $post = new Post(1), it will magically have a User object attached to it, accessible with $post->getJoinedClass(User), where the User object is the user who authored the post.
This also works with fetching a group of objects: $posts = Post::fetchs('`parent_index`=1'); $posts will be an array of Post objects, and each Post will have an attached User.
In the future I will tie this in to the caching support, so that if multiple posts have the same author, the Post objects will all have references to the same User object.

e: The reason this is cool is because it does it all with one query. I've found that the time spent communicating between the database server and the php server is generally the biggest code bottleneck, so my optimization focuses on reducing the number of queries as much as possible. This is a trade-off; this code takes fewer queries, but it takes just a little bit more processor time to execute the extra logic. So, it might possibly be slower when the processor is being completely used by scripts, but in that case I expect the communication bottleneck would narrow as well making this code ultimately faster.


So, without further ado, here they are:

DBRow.php
DBRowTest.php

[Rob Oplawar]

The longer I work on Greeble, the more PHP bugs I uncover. Here's the latest bug I've found (it's fixed in the latest build of php, but not in the latest release of php, which is what I'm using) (it's Windows only; the identical code runs fine on my Linux box):

<?php
 class A {
     static function b($classname) {
        //the following two lines run fine:
        $x = c();
        call_user_func(d, $x);

        //as does this line:
        d(c());

        //this line, however, causes apache to crash. Lovely, eh?
        call_user_func(d, c());
     }
 }
 
 class B extends A{
     public static function a() {
         parent::b(B);
     }
 }

 function c() {
    debug_backtrace();
 }
 function d($x) {}

 B::a(1);
?>

Took me a while to boil it down to its essential components. It requires class inheritance, function overriding, call_user_func, and evaluation of a function in the context of an argument to another function. The crash happens on debug_backtrace().

My suspicion is that there's some sort of infinite loop occuring in debug_backtrace causing a stack overflow.


The bright side is that I can workaround this problem as shown in the two pieces above the disastrous call_user_func, and that the only reason I have a call_user_func in the first place is a workaround for the absence of late static binding in the latest release of php, which won't be necessary much longer.

[Rob Oplawar]

Final bump/doublepost:
greeble.net is now live:

[klange]

All your theme are belong to me.

Thanks for letting me port your site theme. I demand you get that forum working ASAP.