A while back, we casually mentioned in a blog entry that 4.0 would be next major version after 3.4. Development of 4.0 is underway and we're going to be using this new blog to talk about development as we go.
As Brandon mentioned a couple of days ago - the format of these entries is going to be developer-specific. If what we're saying doesn't make much sense right now, we will still be putting announcements up in our main blog when they're finished and ready for everyone to see.
Because of that, it's also worth bearing in mind that everything is subject to change. I'm going to be posting code samples, screenshots and so forth - but everything in this blog is a work in progress - not the final product - and that will probably show.
With that out the way - let's talk about 4.0! :D
The file structure
Currently, applications are mostly self contained in their folders (which is either /admin/applications, /admin/applications_addon/ips or /admin/applications_addon/other) however, other files are dotted around in /interface, /public, etc. In 4.0, applications will be completely self-contained within a single /applications directory.
An application directory will look something like this:
- extensions
- dev
- css
- html
- img
- js
- lang
- admin
- front (it's "front" rather than "public" now)
You will notice the inclusion of a /dev folder. This will not actually be shipped in production, but rather replaces /cache/lang_cache/master_lang and so forth in the 3.x line.
Outside of the applications directory, there will be a "system" directory, which contains core framework classes.
Namespaces and autoloading
In 4.0, we'll be making use of PHP namespaces and using an autoloader. The best way to demonstrate how this works is with a few examples:
- classDb (/ips_kernel/classDb.php) is now IPSDb and located in /system/Db/Db.php
- output (/admin/sources/classes/output/publicOutput.php) is now IPSOutput and located in /system/Output/Output.php
- class_forums (/admin/applications/forums/sources/classes/forums/class_forums.php) is now IPSforumsForum and located in /applications/forums/sources/Forum/Forum.php
- IPSDispatcherFront and IPSDispatcherAdmin are two new classes (with similar functionality to ipsController in 3.x) and both extend IPSDispatcherDispatcher - all 3 are located in /system/Dispatcher/ in individual files.
Better framework design
Where appropriate, classes are being refactored to make better use of appropriate design patterns. One lovely side-effect of this is ipsRegistry no longer exists.
Instead of, for example ipsRegistry::DB() you now use IPSDb::i() - the Db class uses a multiton design pattern (I didn't pass any arguments in that example, which doing will cause the Db class to load conf_global.php and create the default database connection, but I could have passed it a key) - the i method in this case will create the database connection if it doesn't already exist.
To give another example - IPSMember (the new IPSMember) uses an Active Record pattern. So there's no more of this:
IPSMember::isInGroup( 1, 4 );
It's now, the much more logical:
IPSMember::load( 1 )->isInGroup( 4 );
Monkey patching hooks
One of the great things about the IPS Community Suite is hooks - you can easily create a class and instruct the framework to use that instead of a core class.
Now, I don't know about you, but I really, really, really hate having to do this:
$class = IPSLib::loadLibrary( '/path/to/file', 'myClass' );
$object = new $class;
Especially if what you want to call is a static method, in which case it can't be done. You want to of course, just be able to do:
$object = new myClass;
or:
myClass::myStaticMethod();
There is a concept in software engineering to do this sort of thing, called monkey patching, and by clever use of the autoloader, we've managed to make this work. loadLibary and loadActionOverloader are no more.
These points are of course, just the beginning of 4.0. Stay tuned for more :smile: