Jacob Santos

It seems to be a theme with MVC frameworks that they’ll include template engine, as I shudder, a good thing. I don’t believe they realize that there have already been a mass development of template engines and the conclusion that came out of it, was that PHP is already a great template engine. Why create a new language when you can already use the language that you were going to create?

It seems counter-productive. All that time spent writing a new template engine that has gone to waste, because of the strict compliance to the MVC paradigm. I don’t believe people realize that any template engine they create is logic and thus including logic into their views. If you were to follow MVC strictly to the “word” then you spend all of your time adhering to the “word” and not completing the project itself.

What is more important, to spend time building a shitty template engine that is either so simple as to not be worth anything, or so complicated that it creates an entirely new language for which both the designers and programmers have to learn. You can’t prevent or save designers from programming, if they wish to do anything more complicated then HTML and CSS. You can give them better API controls for which to make the coding simpler and faster for them to understand.

That is what I think is sad. Too much time was spent trying to so called simplify the development, that developers failed to realize that development is inherently difficult. You can remove some of the pain and suffering that comes from the complexity, but not all of it. By creating a template engine, you not only hinder the designer who doesn’t give a shit about the template engine and arcane syntax, but also the programmer who has to learn yet another template engine and learn the syntax and how to apply their code to the template engine.

To be honest, I’ve already spent too much time already with the mess known as templating engines and I don’t wish to relive those experiences. I’ve already written my own (crappy) template engine and thought that I was clever using XML with XSLT. I’ve already had to work around another template engine and had to finally just strip most of the templating out of the HTML. The templating engine was worthless, because it restricted the codebase far too well.

Furthermore, I care not about how you write your template engine, you are wasting your time and mine if you wish for me to learn yours. The languages that require such separation are not PHP, which can mix it. It is also true that the paradigm is more about separating business logic and presentation even more, but not too much that the forest for the trees are lost completely.

It is alright to mix PHP and HTML, as long as you don’t mix too much logic or too much code into the views. That is what I think the developers had in mind, but no templating engine will be as well written and featured while working with other libraries and other views and code than PHP itself (as long as the codebases and views are also written in PHP).

I fear that novices and beginners who have entered the PHP development in the past few years have not learned this, but they will or should in the failures of their system in the future. Anyone and most everyone has built a template engine in the past, why continue that tradition when it was a mistake in the first place.

Possibly Related Posts:

• Easier APIs for WordPress
• Libraries Should Use Liberal Licenses
• Why Writing Documentation Wasn’t a Waste of Time
• Contradiction of Good Object-Oriented Design
• Ripping CodeIgniter a New One, Part 2

In part one of the series, I wrote about the advantages of CodeIgniter. I will say that there are quite a few. It is a matter of perspective and I don’t want to do CodeIgniter a disservice by not mentioning a few of them. Perhaps you have more and can comment on that post.

What I want to write about now is rebuttals to several messages mentioned on the CodeIgniter site. It is mean to do so, because I get upset when people point out my idiocy on this blog and elsewhere when I wrote something I think is witty. It is humiliating to find otherwise, but I hope they grow a little from the criticism (or probably die a little inside like I do). Addendum: It was mentioned that many of the arguments are “straw men” and thus weaker than I had originally planned. I resolved to edit and clarify certain positions.

Ripping “Who is CodeIgniter for?” Section

I’ll tell you who CodeIgniter is for. CodeIgniter is for those who want to get shit done and don’t care if the framework they are using is shit. Doesn’t mean the end product is going to be shit, you can avoid the more shitty parts of CodeIgniter (which I’ll get into in Part 3). Just means that if your product doesn’t require more advanced features required for open source or professional web application development, then CodeIgniter is for you. Just don’t expect to create WordPress, unless you plan on reimplementing some of the more worthless parts of CodeIgniter.

I forgot to mention that the other parts in the list, I have no problem with. CodeIgniter does have a relatively small footprint. It doesn’t require a lot of configurations, which is nice because it helps to not have to jump through hoops to get started.

1. “You need exceptional performance.”

   CodeIgniter mentions that it asks for a framework with better performance, I will mention Yii Framework. You could make CodeIgniter faster by requiring the files you need manually. Dynamically loading files does not improve performance. I take issue with the state based on the fact that Yii Framework is faster based on it not dynamically loading every file it needs in the framework.

   While it is true that CodeIgniter is faster than the other frameworks it competes with, it is not faster than Yii. Still there are ways to get around performance bottlenecks in any framework. Dynamically loading files negates the advantages of opcode caching like APC, XCache, etc and you can download Yii Framework library that doesn’t use the dynamic loader. (It is unfortunate that the benchmark I link to pretty much fudges the results by offsetting the real world performance and thus, most be taken carefully.)

   CodeIgniter probably gets away with reducing overhead through its architecture which violates much of what well written code should be. It is an advantage for performance, but you lose maintainability and extensibility. I think this has been my argument against CodeIgniter, is that it sacrifices, so much for simplicity and perhaps performance if it was planned from the beginning to use anti-patterns in its development.

   I could also list many instances where the code is unoptimized for the feature set and could be written to preform better. However, it would be better serve to either submit a patch for those parts or just write my own and learn from those (potential) bottlenecks. I will give it that having less methods and classes is probably giving it a boost over those who use smaller methods and more classes. The speed benefits are minimal and the disadvantages with less extensibility and poor maintainability with larger methods and less classes far outweigh the small performance benefit.

2. “You need broad compatibility with standard hosting accounts that run a variety of PHP versions and configurations.”

   This should be rewritten as, “You need a framework that works on PHP4.” True, I still don’t put much respect on frameworks and code bases that maintain backwards compatibility with past dead PHP versions. However, there is something to be said with staying the course and making those developers and customers happy that are still on those versions. It is most likely a very good advantage to those who haven’t upgraded their servers or are on servers that haven’t, won’t, or can’t upgrade to PHP5.

   The company probably stands behind this statement based on the software they maintain and build. Therefore, while I did put less emphasis on the company and their goal to reach as many potential customers as possible. I might very well be wrong, because they’d be in a better position to ensure that the library runs on more configurations than some of the other open source frameworks who either didn’t realize it doesn’t work or don’t really care about that configuration.

   Still, I look at Zend Framework, Yii Framework, and don’t see many configurations that those do not run on. Of course, not everyone is running on a dedicated server with full control over what they have and even those who are have to weight the advantages over changing their server and configurations for a mere framework. Still, code wise, I’m not seeing many configurations that other frameworks won’t run on. Props on the PHP4 support, although, it is holding the framework back in terms of what they can do.

   I will mention that the statistics for PHP4 and PHP5 had it about even October of last year (2008) and almost a year later, the adoption of PHP5 should have grown considerably. The emphasis on PHP4 has yet to die, but well, if your customers or users ask for it, it is probably a good choice to use an existing framework instead of rolling out your own to support PHP4.

3. “You want a framework that does not require you to adhere to restrictive coding rules.”

   I would rather CodeIgniter adhere to strict coding rules like coding standards as to not have to worry about spaces vs tabs, which it uses both. The statement doesn’t make any sense to me as “rules” can be anything. Restrictive coding rules is not defined. What exactly does it mean? Which framework requires that you adhere to strict coding rules when using the framework or class library? This should be a given. A framework should allow me the option to code how I want within the domain of the framework without restricting my design and coding. Any framework that does, probably isn’t going to be used except by the developer that wrote it.

   As an addendum, the only frameworks I’ve worked with have been Zend Framework and CodeIgniter, and I’ve only looked at the code bases of the others. I think it is reasonable to restrict controllers for various reasons, as well as models. Every framework is going to have restrictions on directory structure, some more asinine than others. CodeIgniter is definitely one of the less asinine with restrictions on directory structure.

4. “You are not interested in large-scale monolithic libraries like PEAR.”

   I’m not sure how PEAR has anything to do with a framework. As well as to the statement that PEAR is large-scale and monolithic, that really depends on which library you are using. Some have more features than others and therefore are large-scale and monolithic to fulfill whatever problem the developer had to solve.

   PEAR is a repository of class libraries. You can use it or not, or use some classes or others. Some classes do have dependencies which require downloading. The advantage is that PEAR class libraries are usually system wide, meaning you only need to have it once. You do have to set the include path for this to happen and as well, if you have many web applications on your server using CodeIgniter, it is completely possible to include it in the PHP include path as well.

5. “You do not want to be forced to learn a templating language…”

   The frameworks and class libraries I’ve looked at and worked with do not require learning a templating language, nor do they even include one. Templating languages are a dime a dozen and including, separately, into your project is something that can be done external of the framework.

   As an addendum, I have finally discovered MVC frameworks that do include templating engines. However, it is fortunate that they will never be used outside of the original developers.

6. “You eschew complexity, favoring simple solutions.”

   Yes, if your solution requires simple for the duration of the project, then CodeIgniter is great for your project. I’ll get into the design flaws of CodeIgniter later. Different projects have different needs and complexity. Some solutions aren’t going to need hooks, theming, etc and are just the model, views, controllers, and some helpers and, or libraries. Others that do, are going to find complexity over what other frameworks do. So I mean, the bootstrapping, models, views, database active record, and controllers are simple enough.

   The problem is that, you are going to miss out and it seems the developers are geared toward simple in some parts, like the Controller, Model, and Views, but retarded in other less frequently used parts. The hook system is a joke, as well as other architecture mishaps. The hook and plugin system are far from simple in any practical terms. Why should I have to jump through hoops when it is done far better in other systems?

7. “You need clear, thorough documentation.”

   If you want to know how well documentation can be, then you need to look at the Zend Framework with both the tutorials that covers almost everything you’ll ever want to use the components for. Also it includes a class reference for all the rest of the missing bits not in the user manual. This happens from the strict coding standards which states that all components require inline documentation and DocBook XML describing how to use the component. Most of the professional, group frameworks and class libraries will have well written detailed documentation, both tutorial and class reference.

   I will say that some is enough. That said, if you can provide the foundation for people to improve upon (and hopefully contribute back) and get started, then the developers should be able to run with it. The hardest part is knowing where to start and once that is realized it is simple enough to figure out the rest.

Source: CodeIgniter User Guide Start Page.

It is of course partially marketing, because you won’t find many frameworks worth using that don’t have these to some degree. I will also say that I have no problem with the other items in the page. CodeIgniter does in fact live up to those statements.

Edit: There isn’t going to be a third part. It was going to go into the architecture flaws, but meh, my fire for dissing CodeIgniter has died. Perhaps I’ll go back to it after I write my own and show how it should be done (or if the case might be, how it shouldn’t be done). I will contend that implementing anti-patterns in a project is a tragedy that should not be. To do so is to burden the maintainers that come after.

Possibly Related Posts:

• Easier APIs for WordPress
• Libraries Should Use Liberal Licenses
• Why Writing Documentation Wasn’t a Waste of Time
• Contradiction of Good Object-Oriented Design
• WTF Are People Still Writing PHP Template Engines

To be fair, CodeIgniter has its advantages. I don’t want to make it sound like you shouldn’t use it, because it is in my opinion that it sucks. I’m sure the company behind it thinks quite highly of it and I’m sure some of those reading this also believe it to be either great or acceptable with their project. Not to take away from the project and those using it, but it is just not the way I would have wrote the framework.

If you would like to know, how I would have built it, then take a look at the Yii Framework. Well, then again, there are disadvantages to using the Yii framework as well, but I’m not going to get in to those until I start using it. Furthermore, to maintain quality and for time constraints, it is probably better to use a framework, which flavor you choose and run with it. No framework is going to be perfect, unless you spend the time to build it specifically for your project and even then, the quality depends on your level of expertise.

1. Short learning curve.

   The advantage of CodeIgniter is that it really does have a really short learning curve. Well, granted I did have an base to build upon, but it isn’t complicated as much as the Zend Framework is to get the code bootstrapped and up and running. The documentation is stronger than most and the structure is such, that once you get past the initial learning phase, you should be building a web application in short order.

   Doesn’t matter what framework you are using, having a short learning curve is almost a requirement. If you are spending more time learning how to use the framework than actually coding then there is something seriously wrong. I do like that it works like others where it can work off a set directory structure to quickly get the controllers and models built, then call the views. Works a bit like Cake in that way, but doesn’t restrict you completely to that set directory path, nor does it restrict you where the directory path is located.

2. You can place the application files anywhere.

   Well, in this instance it does require a bootstrap file, but the bootstrap is far simpler than other frameworks or class libraries. I don’t like being bored with the small stuff and I don’t like being completely restricted on where I can put my files. CodeIgniter gives me enough freedom that I can forgive the other parts and well, it is probably faster when doesn’t have to configure every directory path and just “knows” where to look for the controllers and other files.

3. Robust active record database SQL abstraction.

   I kind of scoffed at the idea, but it is really actually convenient. It is lighter than ADODB, but still has majority of the features. While it isn’t exactly how I would have developed it, it works and it works very well. Likewise, it does have neat methods that speed up development.

   For example, it will return an array of objects or arrays and while PDO does this faster, CodeIgniter does this with MySQLi and MySQL as well.

4. Tutorials and documentation.

   I’m not entirely sure I should give it this one. It doesn’t have a lot of inline documentation or not enough for novices to pick up the parts that aren’t in the tutorials. If you can read code, then the CodeIgniter isn’t anything you should have difficulty with comprehension. Still, some tutorial documentation is far better than none and the inline documentation (that exists) is still better than none. I think it is all that can be asked of the developers to provide who are offering a framework free-of-charge and with a liberal license.

5. Liberal license.

   It doesn’t matter, if you’re not distributing the project. For those who are and want to sell the product, then it will matter. The license is stated to be comparable to the BSD license. Whether that is the New BSD or old BSD is probably going to take a lawyer to parse the legalese. Basically, you can do whatever you want, as long as you don’t say you wrote the library or hold the developers of CodeIgniter liable for any damages using it might cause.

I suppose the advantages compared to others is debatable. There is really only a few advantages here that the others don’t offer. The first is going to be the deal breaker or starter for many project managers. It matters not, if the framework is written well, follows all of the best practices, and is fast, when it takes forever to get people trained and get started with the project. Well, the Yii Framework does have a PHP script that will build your application for you and also build the skeletons for the CRUD for the models. However, the Yii framework is a bit more involved than CodeIgniter.

I suppose in conclusion, it is not for me to decide how you choose your framework or if you even write your own. This is purely an academic exercise. Take it as you will.

Possibly Related Posts:

• Easier APIs for WordPress
• Libraries Should Use Liberal Licenses
• Why Writing Documentation Wasn’t a Waste of Time
• Contradiction of Good Object-Oriented Design
• WTF Are People Still Writing PHP Template Engines

There is a segment of the programming world that thinks they understand Object-Oriented Programming. It is, after all, just functions and data inside of a wrapper right? Well, technically, yes, but that gives an impression and development practice that is wrong. It ignores what OOP tries to solve.

Problem 1: Procedural Programming Limitations

Well, I should clarify that procedural development is not a problem in and of itself. Most simple programs under 100K lines of code or one off programs would probably be better served using procedures (also known as functions in most languages). Well, the general guideline that I’ve read in books and online is <100K lines of code, but I will say that a barrier of maintainability is capped around 10K to 20K lines of code. There are very few developers and projects that I’ve seen where the flow of the project and usage of functions is clear after that range.

The problem with procedural programming is that care has to be taken to logically group the functions and their control flow. To often the APIs I’ve seen hand you many functions and then toss you into the mine field as to how to navigate them. Sure, documentation does a long way, but where is the starting point? However, once you have that, the functions should just work off of that as to what you are trying to accomplish.

The best way is to create a module that is contained and works off a specific set of data to manipulate it. However, given this is akin to how object-oriented development works, it makes more sense to use objects. But, often at the fault of the developer and not the paradigm, the program or project is a mess.

The reason for creating modules is reuse and extensibility. You shouldn’t have to rewrite the same functionality for each project. That doesn’t make any sense, and yes it is possible with procedural programming, but after a while the scope of the functionality becomes far more difficult to separate mentally. What I’m trying to say, is that the API grows so large that refactoring it becomes either impossible given the time and the dependencies that would have to be broken out or understanding of the original problem that the solution was developed for is not possible.

The purpose of an API is for others to understand and grasp it in order to use it to their best ability. When you lack documentation, cohesiveness, and where the true starting point is, then well, hopefully there is another better written API that does what you want or you know enough to write your own implementation. I’ve been there with C/C++ procedural APIs. Well, okay, part of it was my lack of understanding of programming, at the time, and lack of understanding of C/C++.

Problem 2: Reuse and Extensibility

Well, the goal of development is to create a solution that can be reused and extended as much as possible. If a solution is not extensible, then its reuse is limited and it will have to be rewritten or a new solution written that solves a similar, specific problem. What is sad, is that is easiest with procedural programming as you just need to create a new function (when the API is well written) that accepts the main starting point parameters and manipulates or handles the data.

Developing an object that allows extensibility is simple in that you can extend the parent class and add methods and rewrite the parent’s methods. The problem with this, is in languages that only allow you to call a specific object name. So even through you’ve extended the object, you still need to go through the code and change the references to the parent object’s name. One solution for this, is to use the Factory or Adapter Pattern. If you’ve tried the Factory Pattern, then it isn’t really a solution at all for this problem.

Problem with the Factory Pattern is that it is known beforehand what the object name is or you can replace it with your own. You then have another layer on top of your API in order to allow for this type of overriding of the class. This becomes stupid as you have to create layer upon layer just to allow for the caller to correctly get the right class that does what they want when they replace one of yours. Where does that shit stop? Well, it stops when you get bored and start to wonder why the Factory Pattern is useful.

I have to admit that I kind of like the idea behind the Adapter and Plugin Patterns. What I like about it, is that you can extend the base class without having to inherit it and create a whole new object. It doesn’t require a Factory, because the name never has to change. You can also extend it and create new base functionality for a whole new program based off the new object.

The goal should be never to have to recreate functionality that exists within another object. That is perhaps the difficulty with working with objects, is that each object dependencies will be different. This also has to be within the scope of the application.

If you are accessing a file, the API is going to be basic enough to never have to rewrite that functionality (although that is not to mention the at least 3 ways to do such a thing within PHP, not to mention the 3 or 4 ways to traverse a directory). Granted people are going to have their own “way” of implementing similar functionality and some is going to be better than others. That said, I developed a wrapper for the various HTTP implementations in PHP and the wrapper is standardized enough to either be used with the “main” class or alone, so that if you don’t like the main class, you can just ignore it and write your own implementation using the self-contained HTTP transport classes. It isn’t “perfect” in that it still requires code from the main class that would have to be implemented in the new class.

Problem 3: Elegance in its Simplicity

Creating a class library that is both reusable and extensible is extremely difficult and most implementations make it overly obtuse to replace functionality. Doing so, should be clear to the developer that they are just implementing or replacing one component and not dealing with dependencies. The replacement or component should be its only dependency. Forcing them to extend a class or work through dependencies just to implement something simple is not the best or ideal solution. Granted at least an interface will be required, but that should be it and that should allow the developer to use existing classes they’ve built.

Code Igniter forces you to either extend the base class for which it will use your class within its own or to replace it completely. That is a neat trick to say the least, but it is still a WTF? The Code Igniter code base is completely oriented on the Blob anti-pattern with methods that defy completely the C.R.A.P index. Not to mention limitations that should not exist. The work-flow is so ugly, it is great that it “just works,” because going through the code base to fix bugs, well I wouldn’t want to go through that hell.

Well, the advantage to Code Igniter, is that it is extremely easy framework to understand and work off of. The one framework that is more to my liking, Yii Framework, takes a bit more time to understand, but it is also that I haven’t yet developed a project with it. What I like about it, is that it has a great deal more and better features than Code Igniter and the license is better (clearer, better understanding of rights) with the Yii Framework.

The goal should always to create something that is easy to use, but allows for more advanced usage. This usually means creating a wrapper or a layer on top of the API that complements it, to make easing into the API faster, because it is easier to understand. I believe the Swift Mailer and HTML Purifier APIs did a great job in this aspect of object-oriented development. You didn’t have to know about the more arcane parts of the API, you just needed to know what you needed to work with. If you had to, then you could dive deeper into the code and figure it out.

Rehashing the Solution

Quite simply, coding is about making development easy. You, the developer, do the bulk of the hard work, so that the person using your code doesn’t have to. It is often that you’ll use your own code and it is better to not have to recode it. It saves time reusing code and not having to rewrite existing code to work within the constraints of the class library or framework you are working with.

Possibly Related Posts:

• Easier APIs for WordPress
• Libraries Should Use Liberal Licenses
• Why Writing Documentation Wasn’t a Waste of Time
• Contradiction of Good Object-Oriented Design
• WTF Are People Still Writing PHP Template Engines