Indium FrameworkJust another PHP Framework

Well, was about time!
There are still some quirks and issues too solve and not everything is activated. Some libraries still need some love and taken care off.
Some of the DIC (Dependency Injection Containers) is a bit clumsy and doesn’t follow the standards properly. But it works!

So check it out at github!
(https://github.com/Indiumfw/Indium-Framework)

In every process of building an application, tool or what not. You get in a period of dark times where nothing matters then just creating the code. We’ve been in that period now, and hopefully we wont get into that again.

Indium has progressed far beyond what we thought it would do from start. We’ve added lots of feature, which we will be needing for future application work. For instance, a redundant session storage (APC, memcached, Xcache, file, database and more), Form modeller, CLI support, Process handling, MeekroDB support, and more. Hopefully, we’ll get some posts out about how they work and what you can do with it.

We’re in process of building up documentation as well on how to use Indium frameword for application development. As usual, that’s the bit that will always take time and probably most neglected bit. We hope to rectify it as we continue the work.

So here we are, hoping we won’t go dark again!
Until next time!

Indium framework has one point of execution of all runnable objects, the Indium Event. It’s a core object and loaded from start. The idea behind the event it to unify all running events to one point to organise and dynamically change events on the run (with restriction obviously).

Events starts with these default runlevels:

• system
• precontroller
• controller
• postrcontroller
• postsystem

Each runlevel is treated as an ArrayObject for easy manipulation. Another array with the default runlevels registered (not connected to the ArrayObject). That’s the simple buildup of the event. The general idea is that when dispatchEvents() is called it will run through the levels registered and execute all objects. It can be closures or classes which implements any of the InterfaceEvents interfaces.

If you want to add a runLevel during runtime, you can call registerHookLevel($levelName, $hookToLevel).

First parameter is the identifier for the new level and second parameter is which default level it should hook after (note that it’s only after a level a hook will be run). This is good if you want to extend the runtime dynamically.

Registrering an event is quite simple.

First parameter is the name of the event, next is an object (either a closure or a class that implementens either InterfaceEvents or InterfaceEventsParam) and the last parameter is which level you want to register it to. You can add events to a running level (since it will always, for now, put it last) or whatever level that comes after the level you are running. You can never register to a level that’s been done, you’ll get a nice exception when that happens.

You can also register parameters to an event.

First parameter is as guessed wich event to register the params to. And the second one parameter is either an array och a string with the parameter you want to send in to the closure or class. Note, for it too work with classes, you have to implement InterfaceEventParam to the runnable class.

There’s way to unregister events as well on the run, if you want to remove an event that isn’t needed anymore.

This will unregister “Foo” from the postcontroller level. If there isn’t a event with that name an exception will be thrown.

There are some future plans to be able to register events on levels that hasn’t been executed and reorder the execution order for those events.

This is at least the Indium Event handler in it’s simplest form. As you can see, you can have full controll on what will happen and when. Making profiling and optimization easier to work with.

Indium comes with its own includer class called Core\Includer. This class contains a thin set of wrappers around PHP:s native include language construct. In an Indium application, every file system operation that depends on the include_path ini setting should be routed through Core\Includer. Of course, an application may choose to use include or file_get_contents directly, but this is neither supported nor encouraged.

Why does Indium encourage applications to wrap includes?

1. First and foremost, we want to fight a potentially dangerous “feature” of PHP:s includer. If the specified file cannot be found in include_path, PHP will silently search the current directory and the directory in which the calling script resides. This behavior has unpredictable (run time dependent) security implications, encourages the generation of implicit dependencies and imposes an unnecessary cost in terms of file system operations. The only way to turn this ”feature” off is to specify an absolute path, or a path which is relative to the current directory. Core\Includer scans include_path to determin the absolute path of includes before calling on PHP:s native includer.
2. Controlling the scope inside which the include takes place. For reasons of encapsulation and security, Indium has to be able to decide what is visible to an included view.
3. PHP:s includer is a swiss army knife. Wrapping and controlling it helps us in identifying common include idioms and providing standard, Indium blessed methods for carrying them out.
4. We love classes. We want to encourage application writers to use classes. Applications should rely on Indium’s Core\ClassLoader for autoloading.
5. Lastly, wrapping includes enables us to impose strict validation on file names, which helps with tightening up security.

Okay, that’s the Indium includer covered, on to the class loader. The Indium class loader provides a unified and highly configurable interface to class loading. It hooks into PHP SPL:s autoloading infrastructure and sits on top of Core\Includer. Essentially, the class loader provides a mapping from ( namespace path, class name ) tuples to include paths. Include paths may be searched to any specified depth. In addition the class loader has “magic” hooks for Indium exceptions and interfaces; these are automatically searched for in subdirs named “exceptions” and “interfaces”. The best thing about Indium’s class loader and includer is that the appplication need not really care about them. As long as your put your controllers and models in APPLICATION_PATH/controllers and APPLICATION_PATH/models, things are guaranteed to just work.

Core\Includer and Core\ClassLoader has proven to be a very strong and robust combination which gives a reliable and secure foundation to the Indium framework.