There’s many ways of approaching a new project. In the distant past I just started writing and everything was a bit of code on its own with includes for the shared dependencies. One might argue I was using something like MVC-pull, with Views being the main actors that pull in what they needed. Though I wouldn’t call it that as I wouldn’t have known what that meant back then.

Enter CodeIgniter and other frameworks. Instead of starting from the ground up I would hit the ground running. Once the framework was figured out “all” that was left was deciding on how to design the Application within the confines of the Framework. It works quite well, many common tasks are figured out already and you get a pretty complete toolbox right from the get-go. Allowing you to learn more techniques in a shorter amount of time.

This approach has been panned by those critical of monolithic frameworks for the same reason I used the word “confines” above: instead of an optimal solution you handicap your options before you even get started. In many situations this will still be a good bet though, if you know the framework well you’ll be able to develop quickly and satisfy customers for a good price. Maybe not the optimal solution from a code point-of-view, but it works and you are using a reliable base upon which to build.

But the landscape has changed. Instead of the monolithic frameworks of old we now get a choice of many highly decoupled ones. At the same time Composer arose to manage our external package dependencies for us. This allows one to easily pick and choose the best tools for the job. Of course some tools work better together than others, but the direction is clear and I only expect the options to get better with time.

For small projects I’ll keep using existing frameworks. But for larger applications that benefit from their own unique application structure I’ll pick HTTP and routing components that best fit my application design. Thus no longer going the wrong way around to fit my application into a framework’s structural design.

The initial investment is even comparable to that of working with the entirety of a framework: you always have to invest in understanding the inner working to get the most out of it. But now you can drop whatever you don’t like or agree with, in favor of something better. For a project I’m working on right I’m looking to Sf2′s HttpKernel with a Router & MVC structure I’ll write myself. Probably using Zend’s Form class, Twig for templating and Doctrine’s DBAL for database access. Though I might still switch to Frank’s Cabinet.
I’ll figure that out when I get to it. At the time I need it, instead of being bound to the big framework choice of old that bound you to their libraries for the entirety of a project.

One last thought on this: it also decreases your own dependency on the tools written by others. When you build your application on the libraries from multiple sources you won’t have to rewrite the entire application when one of those is no longer developed or gets a completely revamped new version. If you build it right you only have to swap out a single component instead of the whole.
It was you that build the application’s structure, which can remain the same and only needs changes to accomodate a new piece.

After having been actively involved in FuelPHP development for over 1.5 years I have decided to leave the framework. It has been a good run and a very educational experience. But open source development takes time and for the past 5 months I haven’t been able to find that time. As some will know, I spend a lot of time developing what I hoped would turn into FuelPHP version 2.0. While I feel very good about what came out of that I don’t see it becoming distinct enough from other offerings to be worthwhile. It’s been the basis for a few products of mine but I won’t do any more work on it (except for bugfixing).

Looking back to late 2010 I remember where I came from. Having been a CodeIgniter developer for over 3 years I had become disillusioned with the lack of progress and I wanted to start taking advantage of PHP 5.3. I had been hacking the core of CI for the last few months by that time and I knew it no longer had a future for me. But looking at Kohana, Cake and ZF1 I didn’t really see me getting into those.

At about the same time Dan Horrigan and Phil Sturgeon started out on their own little adventure named “Fuel”. Getting involved in discussions on IRC and providing the first Cache library I became something I had never planned on: a framework’s core developer. Harro Verton and Frank de Jonge soon joined to complete the team.

Developing Fuel’s first version (and renaming it to FuelPHP along the way) tought me more about PHP than much of the previous years combined. And, as is often the result of learning, I discovered I was doing it wrong. Well, “wrong” is of course a matter of opinion. But the static way was slowly going the way of the dinosaurs for me. Combined with growing a real appriciation for Unit Testing I decided to put all of that into practice.

During that time Dan had already started on what he wanted to become version 2. And in about the same way I had become a core developer, I ended up taking over the effort and leading the charge.
Developing and thinking about version 2 was possibly even more of an educational experience than version 1 had been. It grew to a state close to maturity in a matter of months, enough for me to start developing on top of it. But again I realized I had made some decissions along the way I no longer felt good about, and it really needs a rewrite to overcome those.

But if I did that, would it really offer something unique over the new frameworks like Symfony 2, ZF2 and others? The landscape has changed a lot since I left CodeIgniter, the offerings have become much more interesting. Combined with the quick rise of Composer one can now easily build his/her own toolbox from many sources without being tied to a single framework. An approach that was gaining my appreciation quickly.

At the same time the thoughts above were developing in my head I made a few choices in my life, among which was the way I do business. It left me no free time to work on Fuel and I started to drift away. In part because I had to work with CakePHP (which I dislike with a vengance), Joomla (which is the biggest pile of shit I’ve ever worked with), ZF2 (which I enjoy) and Symfony components (which I really liked).

All of this means my departure from FuelPHP has turned into little more than a foregone conclusion. But a conclusion I regret because of the worthwhile experience it has been and because of the responsibility I feel towards the community and especially Frank & Harro. A conclusion, nonetheless, which I cannot escape.
I wish FuelPHP all the best for the future and see the work Frank & Harro do with much appreciation. Having been part of this for the birth and growth I can tell from experience how much of one’s personal time goes into a product like Fuel. Appreciate the people who are willing to take on that task, contribute back whenever possible and treat them with the respect they so very much deserve.

(originally posted on fuelphp.com)

This is the 3rd part in a series of blogs on the philosophical design choices behind FuelPHP 2.0. The earlier parts were on the biggest changes and on MVC in general.

Context is what gives meaning to otherwise meaningless or ambiguous statements. This holds true not only in language but in programming as well, or at least it should. Those of you who used HMVC may have run into problems in the earlier versions of FuelPHP when Views weren’t aware of their context. A statement in the View using Uri::segment() might have a different meaning depending on during which Request it was rendered, instead of the meaning it had when the View was created. This was caught and solved early on, but as explained in the earlier blogs, 2.0 will solve this in a more fundamental way.

What do you mean by ‘context’?

The concept of context is similar to Namespaces in PHP: the context (or namespace) gives meaning to particular statements (function/method calls). A call to a model Category may have a different meaning within a webshop and within a weblog. It probably broadly still refers to the same concept, but its context and contents are different. In most cases a category of webshop products (Webshop\\Model\\Category) will have different demands than a category of blogs (Weblog\\Model\\Category). The concept didn’t change (they might even share a base model they’re based on), but the context changed and asking for the category’s items will give wildly different returns.

Another (more basic) example was already given in the introduction. Because of the static interface of FuelPHP 1.x the static calls don’t have any context and thus their return was the same, no matter whether it was called from the main Request or the child of a child of a child request. This was solved by adding a concept of an active request that determined the context of such a call. This made Uri::segment() return something different while the main request was active from when the same call was made while a child request was active.

The next iteration of Fuel will solve this differently: as we’ll become more object oriented every View, Request, Application, etc. will be aware when it was created and/or to which context it belongs. These internal references will allow you to request information directly from a specific context. To illustrate this: when you make a call like $this->app->forge() from the controller you are telling the Controller’s Application to forge an object within it’s ‘context’. And when you call $this->app->env->forge() you are making the same call but to the greater context of the Application’s Environment.

At the same time we’ll keep the active request and introduce the active application references to allow static calls that are also context-aware. This is the ‘weaker’ solution of the 2, as it requires something akin to a global context – something that makes your applications much harder to unit test. (at the same time it will still use the internal references behind the scenes)

Types of context

Now we know what context is we need to define the types that are available during your application’s runtime. One might argue that each class is its own context and one would be right about that, so for clarity we’ll limit the discussion here to those types of context that have a greater importance within FuelPHP.

Environment

The environment consists of those settings, values and functionalities that are defined by the operating system, by the webserver and by PHP itself. These make up a context that should be considered static during at least each HTTP request (should not be changed after FuelPHP’s initialization). Locale and language are examples of this, changing those during runtime might give your output half one locale and the second half the other. The mess of which is obviously something you’d never want.

But also PHP core language concerns should be considered part of the environment. You can’t redefine a classname for example, thus if you’ve loaded a class once with a specific name you can’t load a class with the same name (note: the namespace is part of the classname). Functions, classnames, constants and variables are an important part of the context in which you code lives.

Application

Each application has its own configuration and specific concerns for that application. If you need multiple applications to interact with each other (possible as of 2.0) you need these to be completely separate. But it’s not just the configuration, you will also have utility classes and objects that need the configuration or keep track of your running application – those should live within it’s application context.

Request

The concept of a request in FuelPHP is similar to that of HTTP but not quite. In the 1.x branch each HMVC Request will have its own URI and may have some overwrites but essentially still lives within the same HTTP Request as the main Request does. As of 2.0 this will change and a Request will live within the same Application context as it’s parent Request, but it will also have it’s own context with completely different input variables.

How does this work

In the 1.x branch there is only a very limited Environment context, it consists mainly of a name that allows you to change some configs based on it. But most of its initializing happens in the Fuel class after loading the application main config. This means it is not only tied to the Application, but it is actually so intertwined with it that it cannot truly be seen as different. And when you want more than one application to exist (in runtime or otherwise) this will quickly get you into trouble, as the fixed truths of one application may differ wildly from those of another.

And as the environment should stay constant between Applications, so should the Application constant remain constant between Requests. As noted before, the 1.x branch makes too little difference between Requests. One possible problem with this is that one might want to use the same types of data retrieval for AJAX as one does from within PHP. The way to solve that is to make a Request from PHP that looks the same as a HTTP Request from JavaScript would look. Something that is hardly possible when the input variables cannot fully be controlled. This also exemplifies why the Application’s context should remain constant, otherwise the AJAX Request and the HMVC Request might still lead to wildly different results.

Context 2.0

FuelPHP 2.0 will introduce an Environment object and Application objects that wrap you application. These will maintain the types of contexts discussed here. This is also why Dependency Injection became a central part of 2.0. The Environment and Application objects each have their own object containers that maintain instances within the context to which they belong. But they also have their own forges  (factories) that determines the class to construct based on context.

All Applications one creates within the Environment object will retain a reference to this Environment for context. All Requests created with an Application will be aware of their Application context as well, and indirectly be aware of their Environment via the Application. And the same goes for each and every object instance created.

While 2.0 will still keep track of which Application and Request are currently running, it is no longer the way in which context is determined. The 1.x branch needed to reactivate a Request instance in order to provide the correct context when a View was rendered. In 2.0 the View has object references to its context and doesn’t need any environmental context changes to be able to render itself within the proper context. (FuelPHP will still track this and reactivate/deactive for Backwards Compatibility though, but it doesn’t need it)

In practice

One of the first places where this has already been put into practice has been Oil. Previously Oil was basicly a separate bit of logic, it used FuelPHP’s main parts of course but the application flow of it was completely separate from the logic in a normal request. There where a few downsides to this, for one we’d need to explain the logic of running an Oil task separate from the logic of running a normal HTTP request. Another was that Oil was fully dependant upon 1 application you created, and not really capable of switching between them. The new setup makes Oil a full application within its own right, which can interact with any other application or even package you choose. Because of the new context-awareness a command you give to Oil will be executed within the context of the app upon which you make Oil act, instead of within the context of Oil (another one of the downsides that lead to problems).

The way Oil does this is to instantiate another application by requesting it from the Environment. Then a request is made to that application to execute a request within its context and the result is returned. This will happen in full isolation and non-dependant upon Oil’s context:

// Load the application at 'fuel/example' (remember: applications are packages themselves)
$app = $env->loader->load_application('fuel/example');

// To request something from the other app, make a request upon it and get the response
$response = $app->request('migrate/up')->execute()->response();

The above is just an example but it shows how one might migrate a specific application from another (Oil for example). This would be done by tasks which are now specialized controllers instead of plain classes, this will make the same power available through the command line as you have in a normal request and allow you to work with multiple applications. Something that will be possible and reliable because of the improved context awareness.

(originally posted on fuelphp.com)

While developing FuelPHP 2.0 we took a critical look at all established web application concepts. Nothing was considered out-of-bounds, not even the most well known of all: Model-View-Controller.

When attempting to explain the concept of ViewModels within our framework I often get the question shot back “but what advantage does that have over a controller?” The problem this signifies isn’t that the ViewModel duplicates functionality, rather it’s a symptom of a fundamental misunderstanding of the Controller concept – indeed the whole MVC pattern.

Don’t feel bad if you are one of those people scratching your head over this, it’s a logical consequence of the common and widespread implementation in PHP and other web frameworks. But that’s not where MVC originates, the pattern was designed in the context of old fashioned PC applications. For this type of applications the environmental constraints are very different from those imposed on your web application by the HTTP protocol. And to understand this difference we have to start there.

The origins of MVC

The fundamentals are of course always the same: a seperation of concerns. You divide the logic between the concerns of your application (the controller), the data retrieval/manipulation (the model) and user interaction (the view). But the implications of this in a continous persistantly running application are very different from those on the web that need full request-response processing for each user interaction.

I have seen it argued that this very difference makes the MVC pattern unfit for the web, but I always felt that’s missing the point. The seperation of concerns is always a good idea, a principle more logically sound than MVC is hard to find. The problem however is that the common implementation of a controller and a view no longer fit their original concepts. And when you don’t separate the concept from the implementation, such a charge is actually more of a straw-man argument than an actual critisism.

The common implementation

With a display language (HTML, Javascript) that is different from the backend (PHP, Python, Ruby) some new hurdles need to be taken that were not a problem in the original implementations.

Views used to be entities that generated what was displayed and ran the user interaction. Not the actual actions that the interaction lead to, but it did make sure those interactions were routed to controllers that decide what to do with them. In PHP however the views were HTML, with which came the logical consequence that they are best kept logic-free. Otherwise you’d get an unreadable mix of HTML and PHP in a single file. Something you would expect a decent framework to prevent.

This however does create a problem: the View specific logic has no place anymore…

…and it is where the problem starts for Controllers. People tend to solve this problem by putting the display logic (that has little to do with running the application) into the controller instead. It prevents the unwanted mixture of HTML & PHP in the View, but creates a new mixture of application and view concerns in the Controller. Which completely breaks our original intend when implementing the MVC pattern: seperating concerns.

Another problem is that the concept of a Controller changed. A controller was meant to be a functional entity that handles the application flow and interacts with Models and Views. For the web the Controller was implemented as a class with methods that the routing might lead to. But in almost all cases this fundamentally changes the concept. No longer a single functional entity, but more a container for a set of entities. Entities that for most developers are not considered as smaller parts of a bigger whole. The routing ends up deciding which method is called and the controller has no say in this and is actually little more than a container label.

Which introduces the concept of routing in a web framework. Without the persistant state of a PC application we can’t couple a View interaction directly to a Controller call, it needs a new HTTP request to do that. And the new request runs completely isolated from the previous one. Routing adds a new layer of logic to this that takes the input and decides which controller will be used.

Ok… why does this matter?

Obviously these implementations were done for a reason and they are not bad in themselves. But the problem of an implementation that gets copied instead of the concept is that the concept and its intentions get lost. Which is what happened with MVC. Views became incapable of doing anything functional, and of the controller concept little more was left than buckets of loose sand.

Something new arose that shouldn’t really bear the MVC label anymore.

But things also started to get a little bit confusing. The Laravel framework for example introduced the concept of MVR (Model-View-Router) with routes that contained Closures instead of Controller class paths. The problem here is not the executable routes themselves, a fine concept we have implemented as well. The confusing part is the label, which implies that this is something new and different while it isn’t: An executable route is a functional entity that handles the application execution based on user interaction, also known as a Controller.

(note: this is not meant to be a dig at Laravel, it is just an example of how mixed up the terminology has become)

How does FuelPHP handle this?

In our current stable 1.x branch we handle Controllers pretty much like everyone else. Routing is done to methods (“actions”) and the Controller is little more than syntax. Closures/callbacks are also allowed and handled differently from Controller classes (implying they’re not controllers).

ViewModels are already a part of the solution. They are functional entities that handle the view logic and decide which “view” (HTML template) to call. This allows you to remove any view-specific concerns from your controllers. In our implementation, ViewModels are not really a new concept. They are in fact more of an implementation of what Views should be in MVC. Making the common PHP implementation (of view files containing HTML and variables) little more than another resource loaded by the ViewModel, just like a config or language file might be loaded.

In the current alpha of 2.0 we went back to the original concept even further. Routing is no longer a simple bit of string manipulation to translate an input URI to something that maps to a Controller’s classname. Instead, routing now always returns something executable, whether that is a Closure, a callback or… the common instance of a Controller class. This last part is handled by giving the Controllers a PHP magic method __invoke(). This will allow instances of the class to be called like a Closure.

The executable controller returned by routing gets passed an array of URI segments that may help it decide what to do. In the case of a controller class this will most likely be calling an ‘action’-method.

While this will be mostly philosophical to many users, with little practical implications, it is not trivial. Interpretation and implementation of concepts is important. And to keep the concept of MVC relevant and useful we should remember how the pattern was meant to be implemented, not just the implementations we learned first. This is part of our job while continuing to develop our framework, especially when working on a new version and re-evaluating concepts and implementation.

(originally posted on fuelphp.com)

A question that has been asked many times about 2.0 is “why the big changes”, in this blog I will attempt to explain the choices made and place them in context. But let me also begin by saying that if there weren’t any big changes in it, it wouldn’t be a 2.0 version but just a 1.x version that got bumped beyond its station.

First to ease some of the fears: we will make a static interface available for 2.0 classes and a Legacy add-on that will almost completely mimic the 1.x usage. And for those classes that already work primarily with objects after forging them: little will change but for the way you forge them.

A bit of history

Fuel began when Dan broke with CodeIgniter because it had become stale in his, mine and many other minds. It’s codebase had been written originally for PHP4 and as they never took a leap and broke with the old base it was basicly still a PHP4 framework at the time (and even though they got the community involved to expand it, the architecture remains unchanged).

With the CodeIgniter experience and knowledge he started Fuel and was joined by Phil, myself, Harro and Frank. All of us came with backgrounds in an array of frameworks such as Ruby on Rails and Kohana, but mainly CodeIgniter. We had the desire to create a more modern framework, for PHP 5.3 taking on board some of the lessons learned by other frameworks.

I feel that with 1.0 and especially 1.1 this was a goal we reached. For me the framework allowed my applications to grow beyond what would have been possible in CI.

But as we improved we also took some baggage with us that stayed in one way or another. We got rid of the Singleton-like core class concept and implemented everything as static Multitons. Which is an improvement over CI, but still has the downside of a global scope. And this became at the same time our biggest boon (easy static syntax and instances available when required) and our biggest limitation (global scope).

The global scope gave as various problems when we started to think about where we wanted to take the framework next. But most of all it was very hard to unit test some of the most essential core classes. And the lack of unit tests has given us problems with each release that should have been easily preventable.

The next step

Some of the plans for 2.0 already entailed:

• wrapper objects for applications (allowing multiple active applications in runtime)
• wrapper object for the environment setup
• input overwrites for each HMVC request
• replacing the multitons with a Dependency Injection Container (DiC) behind the scenes

As you may conclude this means some new layers that give more context to your application than currently available. Right now each application is at the same time its environment and really doesn’t differ that much from the controller context. To get that to a level that allowed for nesting multiple application objects that live within an environment object, I had to eliminate pretty much all the global scope available. Which in the end came down to eliminating all static methods as all those broke context and could take an application context from global while working inside another.

When the essential core classes became ignorant of global so had everything else. Where 1.x had had essentially no inversion of control, 2.0 is suddenly using a DiC and setters all over the place. Where the global state had been binding things together in 1.x, the 2.0 code is held together by a beautiful object graph.

What does this mean?

The most important improvement is that it will be possible to test every class in full isolation, thus making unit testing much easier. Having the core fully unit tested will also be a requirement for the first 2.0 release.

Most of the core classes you use regularly won’t really change. Views will still be Views, Controllers are still the same thing and most of the current libraries will be ported over with little functional changes (except for those mentioned on the roadmap). But as you may have understood by now the big change is that the Core packages of 2.0 will no longer contain static classes. That doesn’t mean that the syntax is gone for everyone though, those of you who don’t mind a global state but do want the new and unit tested codebase will still be able to make the old calls on the new codebase using static calls. And of course nothing has to change either in your own classes, if they were static or if they aren’t fit for usage with a DiC: autoloading will still work as before and no code needs to be changed on that account.

But what will the new non-static syntax look like? Some of that is not yet clear, and we are still thinking about improving it. But one thing is for sure: any core class object always needs to come from somewhere, either as an Environment, Application or Request property or from the Application DiC. Classes like the Controller and ViewModels (renamed to Presenter in 2.0) will have references to the Application object that created them.

Here’s an example:

// 1.x / 2.0-legacy-enabled
$var = Input::post('var');
// 2.0
$input = $this->request->input;
$var = $input->post('var');

And for other things the difference is smaller:

// 1.x / 2.0-legacy-enabled
$val = Validation::forge();
$view = View::forge();
// 2.0
$val = $this->app->forge('Validation');
$view = $this->app->forge('View');

I know this looks like a step backwards to some of you, which is why we will keep the static interface alive. This might look somewhat like the CodeIgniter loader but is completely different. It acts just like the existing forge() methods in each class, pumping out instances to be used however you like.

We realize many of you fell in love with the simplicity of the mainly static auto-loaded class names. Where you can start working with a class by just talking directly to it without a loader, but there is also a significant downside to that. When it comes to unit testing there are two strategies called called “Stubbing” and “Mocking”, which involve faking a class to see what one class is passing to another. This is near-impossible to do if class A is talking to a static class B, as there is no way for us to “inject” a fake class B.

It also helps massively with HMVC, as Input::get() is global, but we want to have different input available so that HMVC requests emulate HTTP requests perfectly. Doing this allows developers to build up API-driven systems, then use HMVC to call that API, cutting out a HTTP request. But with the static usage the global query string of a controller could interfere with the HMVC request, causing all sorts of problems.

The static interface will continue to exist via a Static package and the Legacy add-on, but the purely OO usage is now the bread-and-butter of Fuel.

The bottom line

We are moving forward to become a better designed, unit tested and in general more flexible framework. For that it is necessary to break with some of the baggage that limits us in what is possible. At the same time we do not want to leave our 1.x users in the cold, which is why development of the Legacy package is a big and important part of the 2.0 development. But we did separate these to make both a clean break and at the same time be able to provide backwards compatibility.

A short note about the speed and memory usage resulting: at this point baseline 2.0 compared to 1.1-dev showed to be about the same speed (~7% slower on a Linux server, ~25% faster on Windows laptop) as wel as memory usage (<2% more on Linux, ~7% less on Windows). These are too early for any final conclusion on it, but are indicative of what is possible.

[late update march 13th: 2.0 is now about 7% faster and uses 8% less memory on Linux after some more optimizing]

(originally posted on fuelphp.com)

Recently we’ve had lots of feedback about  some of the ways in which we handle things likes namespaces, underscores in classes and the occasional bit of PascalCase in our class names. This article intends to clear up any confusion and explain to you why each decision made is a direct improvement to Fuel.

Let’s first go over how autoloading works in Fuel:

• Namespaces are linked to an “area” of Fuel: Fuel\\Core is linked to fuel/core, the global namespace is left for your app, then packages and modules each have their own.
• Underscores are translated to directory separators, which means Controller_Example is in app/classes/controller/example.php
• Filenames and directories are all lowercase

We know this isn’t fully compatible with proposed standards like PSR-0, but a framework is entitled to its own standards and conventions and we chose ours carefully. I’ll explain below why the choices were made, but it’s also important to know that our autoloader is very efficient. You can add any other autoloader on top of ours and once ours is done after 1 or even no filesystem checks the other one will kick in. Thus compatibility with PSR-0 is easily added without meaningful overhead.

Now on to the choices we made for Fuel.

Namespaces

We’ve tried multiple implementations, among which were having the App in its own namespace and converting sub-namespaces to directory separators. But in the end we kept running into one thing we felt was a problem: PHP doesn’t allow you to import all classes from another namespace into your current one. Which means for example that if you’re in “Fuel\\App\\Controller” you’ll have to import (“use” in PHP terminology) all classes from “Fuel\\App” or call them with full namespace attached. And this goes for all sub-namespaces.

In the end a choice was made we felt wasn’t perfect but it was the best of multiple evils caused by the way PHP has implemented namespaces. Your App resides in the global namespace, something we feel is acceptable because everything else should be namespaced while your App is the main part and has a right to be in global.

The Core was given its own namespace in “Fuel\\Core”, and its classes are automatically aliased to global when called from global and unknown there. For example calling the class “View” will fail if you have no such class in your App, but then it looks into the “core_namespaces” in the autoloader and finds a class “Fuel\\Core\\View” which is loaded and aliased to “View”. (you can also add more core namespaces which will function the same way, the Auth package works like that as well for example)

Because of all this the utility classes are always available in the global namespace, and when you call them from a Module or Package you can be sure that they’re available like “View” and not “Fuel\\App\\View”.

Then came packages and modules. These were some more complex decisions but it came down to this: we feel that classes from either a package or a module should be usable everywhere else as well (when you’ve loaded the package/module that is). If we put those in “Fuel\\Packages\\Pkg_name\\Classname” they would be awful to reach, which is why we decided to put them in just a single namespace. “Pkg_name\\Classname” is easy to use and to remember.

Cascading FileSystem (CFS) and how namespaces changed that

One of the things that was inspired by Kohana is the way we’ve setup our filesystem. The basic idea was that you can copy your core/packages/app all into each other and things would still work. The way this was done was by prefixing all core classes with “Kohana_” and have empty extensions of those classes without the prefixes. Now if you were to extend such a class you would just create the class without the prefix in your App and extend the original class with the prefix (which would be taken from core). Namespaces changed all that.

When we decided to start using namespaces we also decided to bind them to specific areas within Fuel. This means that there’s no longer a problem when you have an extension in your app and one or more packages. The App will always take precedence over anything else, but the others can still be used when you include the full namespace. This made the use of another prefix like “Fuel_” unnecessary as the namespace bound to a specific location already did that job.

The Fuel CFS is no longer the same as Kohana’s CFS, but its remnants are still visible. The same ease of understanding to where a class can be found still applies, because you know exactly where to find any class. It will be a direct representation of its class name, in a subdir of classes of its namespace “area”.

Note: views are still loaded in the same way as Kohana’s CFS. Config and lang files are loaded from core, packages and app and merged with the later ones taking precedence over the earlier locations (current module comes last when the current controller is part of a module).

Underscores

We’ve explained why namespaces don’t simply map to directories and why we don’t make extensive use of sub-namespaces. But we still need to have a clear directory structure. By keeping this pre-namespaces convention of translating underscores to directory separators we allow the advantages of having things in the same namespace (no importing classes, no fully namespaced class calls).

Fully lowercase paths

This decision was taken because basically we feel it leaves less room for mistakes. A common error in other frameworks is that files that should be uppercased on the first letter end up lowercase and vice versa. In many development envronments such as OS X the file system is often cases insensitive so this does not error, but as soon as the project is deployed to a case-sensitive live server things all fall apart.

Instead of having to check if you got every uppercase/lowercase character right in a full path, you only have to check if they’re all lowercase.

(Originally posted on fuelphp.com)

Yes, we use static classes. So that must mean the principle advantages of dependency injection are impossible right? Wrong.

Dependency injection is about making it possible to completely replace a part of the composition of objects that work together. To reach this goal you should never use “new Object” but always expect the new object to be given or set on your class. The reason you don’t use “new” is that you don’t want to be tied to that specific class, you want to be able to “inject” another implementation without trouble. It is however still possible to use the object because you know what interface it extends and you know what to input and what to expect as output.

In Fuel we don’t use or implement Dependency Injection in the sense that we use setters or in the sense that we give a specific object to the constructor. Thus this blog is meant for those open to alternative solutions, those interested only in the specific aforementioned implementation are probably best served elsewhere.

We have implemented the framework in a way that allows for complete replacement or extension of a class without rewriting a single line outside of that class. This has been done in 2 ways:

Extensibility

In Fuel any class from the core can be extended or replaced in the global namespace. This new class will then be used by the core classes as well as by your application. The way this has been done is that all core classes live in the “Fuel\\Core” namespace and when a class like “View” is requested and not loaded into the global namespace we check the Core for the class, load it and alias it to global. If you want to use another implementation you can just extend or replace the core class in the application (or a package) and register it with the autoloader. After that your implementation will be used everywhere instead of the original Core class.

This isn’t really injecting of course in the classic way, it uses an expected classname to access an unspecified class. Thus the injection is in a way to the expected classname.

The question is if this is really that different from expecting a specific interface. It may not look like classical dependency injection, that doesn’t mean it can’t reap the same benifits.

Factories/Drivers

Another way we have used to implement the principle of dependency injection is by using drivers for some classes. The Session class for example is always accessed through either static usage or creates a new object with a factory:

// use your default driver to retrieve a value "some_var" from the session $some_var = Session::get('some_var'); // use a specific named config to retrieve a value from that session, you can change // the config if you want $session = Session::factory('admin'); $some_var = $session->get('some_var');

To some this may look like a fixed class, but in truth you’re workin with Session_Cookie, Session_Db, Session_Redis or any other driver you might configure it to use. Again in this case: nothing is set on my object or given as a construction arguement but I can replace/configure it to use any replacement or extension I want without changing the existing code that uses the implementation.

Bottom line

While we haven’t implemented Dependency Injection in the classical sense, we do allow you to “inject” anything you want. The limitations for both the classic and our solution is that the interface must stay the same, but instead of expecting a variable on your object you can use static class calls. I know that we’ll never agree if you’re a purist/evangelist, but if you’re a pragmatic coder our options with drivers & extensions will probably serve your needs just as well.