We believe that neither a framework nor a CMS should be difficult to install, configure or learn, nor should they make anyone program in a rigid or cumbersome way. In other words, they should make programming more – not less – fun. It should however take away a lot of the tedious stuff – the things that distract you just when you were getting some really good ideas.
The philosophy of making software for developers
Eliminate the tedious. Well that is basically the idea of a framework. We want to give you a frame that takes care of the boring things that are always there and let’s you do your stuff. All frameworks should fulfill this function, otherwise they don’t deserve to be called frameworks.
Don’t take away the interesting work. We want to let you, the developer, write your own code in your own way. We want you to have fun programming. Most developers enjoy programming and don’t want all the work taken care of.
Don’t make the developer do awkward things, like dealing with complicated class systems or even learning a new scripting language or templating markup, just to work with one particular framework or CMS. Of course, learning is necessary in order to work with any unfamiliar system, but it can be kept to a minimum and the more you can use what you already know, the better. Keep it simple, don’t just say it is simple. Don’t organise because of a misguided love of organisation or because that is “the way it is supposed to be done”. Inheritance is great, but hard to follow in a framework. Conventions only help those who have memorized them.
Never implement features that “might” be useful. Make what is needed, when it is needed. A basic “getting real” principle, worth gold in a project by developers for developers.
Because of these principles – or at the beginning at least a vague idea of them – we set about making a new framework, and later built a new CMS.
Are these ideas so unique? Certainly not, but we have seen few examples of products for developers that follow them, and lots of tools that are difficult to install, learn and are useful only after extensive learning. Tools that lead developers to describe themselves according to being able to work with them. We don’t want developers to write „MorrowTwo Developer“ in their CV instead of „PHP Developer“. That doesn’t make sense. Any more than an illustrator describing himself as a „pencil pusher“.
A philosophy of simplicity has found broad acceptance in web development, an approach that begins at the birth of every new project. But it seems that tools for developers are still expected to be complicated and full of features. Maybe because developers have a hard time thinking „simple“ and, to be honest, it wasn’t easy for us either.
Re-programming and avoiding featuritis
Morrow – the forerunner of our framework “MorrowTwo” – began as a project our own use. The first ideas came about as we started combining the systems we had each created for ourselves as individual developers. Starting in a kind of pair-programming process, we created Morrow – a full framework, that we considered more of a proof-of-concept than a finished version. After using Morrow in dozens of real projects, we sat down and discussed all that was good, and all that bothered us.
First of all we re-defined the way classes were to be used and refactored the way controllers work. But going further than that, we realized that we still took too much of the programming away from the developer. We had created a lot of conventions that allowed the developer to do things in a single line of code. The problem with that, was that the developer had to learn these conventions in order to use the features. Therefore we threw them all out. The consequence is that you, as a developer, have to write more code, but it is code that you write without having to refer as much to the documentation.
When we started working on our CMS “/f/” (pronounced “SlashF-Shift7”* or just “SlashF”), we had already gained a lot of experience with working with eachother and had learned to look for the signs of featuritis creeping in. For every feature one of us wanted to add, the other asked the question: Do we need it? Do we need it now? Most of the time, the answer was “no”. It was actually quite like a game.
The results of these processes, I would now like to decribe in some more detail in the next two sections.
MorrowTwo: efficient web development
What does efficient mean? It means no set up and no configuration of the framework itself. It means understanding quickly how the system works. It means the basics are taken care of and the developer can program his in his own way.
What are the basics? In our opinion they are: a simple controller/template setup. It includes a simple handling of user input, provides speaking URLs automatically, helps in the generation of valid links and navigational elements. Also multiple language and locale handling are a must. Multiple projects and sites should also be possible. And of course logging and debugging should be simple and ready to use. Ah what else? Of course, session handling and output to different types of views with the appropriate headers.
When all that is basic, what could possibly be optional?
There is quite a few left over. But instead of giving you a complete feature list now, I would like to refer to the project wiki, which provides you with the documentation of the classes we provide with the framework. If you feel like anything is missing, you can create your own classes, or use classes provided by other developers.
There is one more very important feature to mention. Programming easily isn’t everything. The product you develop also needs to be efficient. We have trimmed MorrowTwo for performance. The entire code has been analysed with XDebug and then optimised. To increase output speed even more we have implemented a soft HTTP-Caching with automatic generation of ETags. You don’t have to do anything for this. But if you really want to decrease the expenditure of your own code you can also implement hard caching by using the classes we provide for that.
SlashF-Shift7: Just managing content
Managing content is a difficult topic. We decided to make it easier. Not just for the editor of the content, who should not be confronted with too many options and ways of doing things, but also for the developer. Our goal was to allow you to set up the content managing part by creating a few configuration files. That’s it.
As a main concept of the CMS we separated the management of content from its presentation. In order to present the content, you, the developer, can use a framework, like MorrowTwo, or just write your own PHP code. You can get the content then either directly from the database or can use a class that we provide to access page data. The two biggest advantages of this are that the output is not limited to HTML and you have complete freedom to program in the way you are used to with the technologies you are used to using.
For managing the content you have a range of fields that you configure to your needs. You group these fields together to form data sets for pages or list items. If you need your own custom fields you can add these by extending classes that we provide. The result is an interface that is easy to understand for those who will be adding and editing content.
Keeping ourselves to the essential features, the decisions we made were initially based on experience. We only put in features that we have actually needed for real projects, but not ones that sounded like good ideas, but we have never actually used. The list was then adapted to needs that came up in the subsequent projects we realised for ourselves and our clients.
At the current stand, we have a preview and publishing system, simple group permissions, automatic support for “speaking URLs”, and simple file management including IPTC field editing, to name a few features. Of course, /f/ has been set up to handle multilingual content from the very beginning.
Currently /f/ is in the refactoring phase. When that is finished we are also planning to provide it for you for free.
Creating and sharing
Basically it is not hard to program for developers. From the beginning on, you are making something for yourself. When the goal is to make something that you can enjoy using, if you remember – and keep reminding yourself – to only implement the necessary and keep in mind that others could use your application and that they should also have fun with it, then you are likely to create a great product.
MorrowTwo has been used for years now by Ministry employees and freelancers working with us. The feedback we have received has supported the ideas above. Once you have tried MorrowTwo yourself, we would greatly appreciate it, if you would share your thoughts and feelings about the framework:email@example.com.
If you would like to be notified when /f/ is availible to the public, write us at firstname.lastname@example.org.