This Yii 2 mailer tutorial implements a method to send response messages via email to users of the application. This is sometimes called an auto-responder.
This tutorial is not included in my book, Yii 2 For Beginners, but I thought it would make a great addition to the template that the book builds.
This is not a short tutorial, even though in reality, there isn’t much code. The reason is that we are not only going to talk about how we are approaching our methods, but also why. The why is very important.
A couple of years ago, I discovered a youtube video that talks about how important “why” is, and ever since then, I’ve made it part of my lesson plans.
Also, my blog is geared toward beginners, so I take great pains to explain in great detail what we are doing, what decisions we made, and why we made them. We want to not only advance your understanding of Yii 2, but we also want to learn a little about design principles and their application.
The goal, as always, is to make the final code as pretty, thin, and usable as possible. Ultimately, the email trigger method will be in a controller, so we always want to keep that code as clean as possible.
Let’s start with a warm welcome to anyone from around the world who is just discovering this blog. Over 1000 developers have taken part in the polls on this site and I would encourage you to participate, let your voice be heard.
Also, thanks to everyone who has bought Yii 2 For Beginners, I appreciate your support. Starting this week, I will be adding tutorials on Yii 2 that build off of examples in the book, so I hope this can be a great resource for you.
Ok, so what is up with $foo and $bar? The use of $foo, and it’s companion $bar, in examples and lessons has always bothered me. One reason for that is that I know the origin of the composite word, Foobar, which is derived from fubar. Fubar is an epression that started in the US military. It stands for “fucked up beyond all recognition.”
So once upon a time, in the early days of programming, someone apparently thought it was clever to use a phonetic variation of fubar, split in half to use in programming examples. In other words, it was a joke. It was a joke, however, that caught on, and so now we seem to be stuck with it.
So what’s wrong with that? Ok, here’s the problem. Some people, like myself, know the origin of the word. The word itself has meaning. That meaning gets injected into the example on a subliminal level, which distracts from understanding the objective of the lesson.
Also, since $foo and $bar combine to represent a single word, the first thing I always try to see is if they are meant to be related that way when they are used in an example and more often than not, they are not meant to be related, though in some cases, one is used as a child of the other. You can see how confusing this can get.
It’s not that I don’t have the brain power to overcome the inference of fubar, but on the other hand, I would rather not waste bytes or neurons, precious as they are, on something like that. I have a much better use for them elsewhere.
Now you could say I’m in the minority, and that most people, especially those around the world who don’t speak english as a first language, are not going to have that distraction and you would be right about that. However, $foo and $bar still make for bad examples. Here’s why:
Even without the inference, using $foo and $bar is like using $could_be_anything_1 and $could_be_anything_2 or as the way my brain sees it, $lazy_example_1 and $lazy_example_2.
Wouldn’t be better for example, if you were going to explain arrays to people, to do it in a way that also points them in the right direction for future use and future lessons. For example, here we have a snippet from PHP.net on the new array syntax:
// as of PHP 5.4
$array = [
"foo" => "bar",
"bar" => "foo",
And look, they used my favorite word for the example, I didn’t have to go far to find someone using it. So just to reiterate why this is so bad, the first key is foo and has a value of bar, the second key is bar and has a value of foo. Does this mean they are interchangeable in the code and that they are equal to each other? Of course not. Arrays don’t work that way. But imagine you were just learning. You could see how that would potentially be confusing.
Robert Martin, Author of Clean Code, uses an interesting phrase, “lies and disinformation.” He is referring to comments in code that grow outdated in time because they are not maintained as the code changes. A bad choice of language in tutorials and examples is just as harmful. It slows down the learning process and makes it less fun.
Imagine the poor guy just learning PHP and programming having to spend an extra ten minutes of his time to realize that foo and bar are not equal to each other. If that happened to me, I would be angry and want my time back. Nothing is as precious as time and anything that degrades it in a learning enviroment is as bad as “lies and disinformation.”
Imagine an array example instead:
// as of PHP 5.4 example array named basket, where “string” is key and integer is value:
$basket = [
"apple" => 1,
"cookie" => 4,
Now obviously, there is a little more color to the example. Also I added more to the comment for clarity, even though those aspects might be explained elsewhere. It doesn’t hurt to have it there, because when people do a Google search, they may come directly to this snippet, you never know.
Why choose the word $basket? Well, what would a future or current programmer possibly work on that would require an array? That list is probably endless, but one good example would be a shopping cart. And right away, as a human, I’m a lot more interested in the example. Arrays might be fun if I can play with apples and cookies. I might even start to get creative about what I can do with the basket.
So obviously this is as basic as it gets, but it does have implications. We have seen a movement in modern PHP towards more clear snytax, and what I mean by that is code that makes its intentions more clear.
The modern PHP frameworks like Laravel and Yii 2 have done a good job making the code more intuitive. In fact I think Taylor Otwell, Laravel inventor and developer, has been very influential in this regard. I initially found his framework very attractive, but then Yii 2 came out and as you can tell from the history of this blog, and the book I wrote about it, I fell in love with it.
An example of excellent and intuitive syntax in Yii 2 is the behaviors method that you can use on either a model or a controller. We’re about to take a quantum leap in complexity from the array example, but as long as we give a good example, we will understand it.
A typical implementation of behaviors in a model would look like this:
public function behaviors()
'timestamp' => [
'class' => 'yii\behaviors\TimestampBehavior',
'attributes' => [
ActiveRecord::EVENT_BEFORE_INSERT => ['created_at', 'updated_at'],
ActiveRecord::EVENT_BEFORE_UPDATE => ['updated_at'],
'value' => new Expression('NOW()'),
Screenshot of the code with no scroll:
If you are following along from the book, this example appears in the User model and Profile model. We use a different type of behavior for controllers, but you can get a clear idea of how cool and how flexible this concept is.
TimestampBehavior is one of Yii 2’s out-of-the-box behaviors, so everything is in place that you need to attach it to any model. All it’s doing here is automatically setting the value of two attributes, ‘created_at’ and ‘updated_at’ with a ‘value’ of ‘NOW()’ before insert or update.
This means before any record is created or updated, the timestamp value is set, and, assuming that you have the corresponding columns on your DB table in DATETIME format, you will get the desired result and the fields in your table will be updated with the current DATETIME.
Can you see how intuitive the concept is and how clear the code is? Anyway, let’s just step through this to make sure we understand it.
By configuring the behavior, we influence how the model will work. We give the behavior a name, in this case ‘timestamp.’ We tell it what class to use, in this case ‘yii\behaviors\TimestampBehavior.’
Next we tell it which attributes we want to affect, and we use ActiveRecord::EVENT_BEFORE_INSERT to tell it when and how to use it. In other words, it will set the value of the attribute before inserting or updating, which is made fairly clear from the name of the event.
And then finally, what ‘value’ we want to give it. We’re using an instance of the expression class, which let’s us define what type of value we want, which allows us to pop in the MYSQL syntax ‘NOW()’, so ActiveRecord can hand it into the insert statement.
You know the syntax is well-written when it is easier to understand than the verbal explanation. At least it seems that way to me. I’ve been staring at it for a while now. It just seems clearer and clearer to me, which is always a good sign.
Now imagine the above example as:
public function behaviors()
'foo' => [
'class' => 'foobar',
'attributes' => [
qux => ['baz1', 'baz2'],
qux => ['baz2'],
'value' => new Expression('quux'),
Screenshot of the code with no scroll:
That’s not realistic, no one would do that to you, at least I hope they wouldn’t. Anyway, I think you get the point. A real example makes you want to play with the system. A $foo/$bar example is just fubar. Feel free to take the poll and let us know what you think.
I’ve been studying the PHP framework scene for the last 3 years in depth. I’ve done comparisons on all the major frameworks, including Laravel, Symfony, and Yii, and in the end I chose Yii 2 as my framework of choice. You can see a little of the history of this, my blog, Yii 2 vs. Laravel, talks about discovering Yii 2 when it was only in Alpha. After trying all of the other frameworks, watching countless videos and reading many books, I settled on the one PHP framework that had no book whatsoever to help beginning programmers.
I always felt, if only there were a book for beginners, I could learn this quickly, I just needed someone to point the way. Instead, I learned piecemeal by gleaning tips from the forum, the guide, and from the fact that the framework was very intuitive. Even though I made progress, I still found myself wishing for the book. Learning this would be so much easier, if I just had a book!
How ironic is it that 6 months later, I end up writing the book I yearned for? Well, I kept very detailed notes on my development and I noticed over time that I could organize them into a book. I just had to be willing to sacrifice the time, which could have been spent developing actual sites, which instead had to go into writing lessons for other people.
It was a tough choice, but I chose to write the book, it seemed like a worthwhile endeavor. It turned out to be an incredible challenge. It pushed me mentally and physically. I spent long nights picking apart every detail, striving for excellence and clarity, so that others could more easily understand how to use Yii 2.
I started out fairly objective about PHP frameworks, simply looking for the easiest framework that could support robust development. Although I had a lot of respect for Symfony, I felt it was overly complicated and bloated. I didn’t like having to learn Yaml, even though it’s not difficult. I didn’t like having to write every route through the site. I didn’t like what I saw of doctrine. And I didn’t like the fact that alhough they had beautifully written documentation, there was no real effort made to service beginning programmers. This has a downside for businesses that have to hire programmers because it then becomes more expensive to train programmers. So in that sense, Symfony is an expensive discipline.
Laravel, on the other hand, went out of it’s way to service beginners and I loved that about it. The problem was, I just never felt like they were helping me build anything. None of the examples I found at the time, for example, dealt with a robust user login and verification. And without that, what kind of site do you have? And then, because it’s built on top of Symfony, it brings in Symfony’s bloat and performance issues. The other programmers at my company didn’t like it either. It didn’t seem robust enough to them, though in fairness, I should say that it was very new when we were doing those comparisons.
I turned to Yii 1.1.14 because my company had settled on it and the programmers loved it, but I found it difficult to grasp personally. In retrospect now, since I came up to speed on Yii 2, I understand 1.1.14 a lot better, but at the time, it seemed so difficult to use. The reality was that it was difficult to learn, but easy to use. You just had to be at a certain level as a programmer to get that. I hated that about it.
Then I discovered Yii 2 and everything changed. Whereaas Yii 1.1.14 was old and ugly, using old array syntax, no namespaces, etc., Yii 2 was a beacon of modern PHP. And being beautiful architecturally in this case is not just a superficial thing, it is extremely versatile and useful, way more intuitive than it’s predecessor. I have so much enthusiasm and passion for it, that I want to share it, and this was one of the motivations to write Yii 2 For Beginners.
Also, I know that right now, a beginning programmer is wandering around, wondering how to go from novice PHP programmer to framework developer. That’s a tough transition to make. I know just how frustrating it is. I want to help.
There are many, many, more advanced, and more qualified programmers than me, who apparently don’t have time or the interest to bring it down to the beginning level, so that task has fallen to me, at least in the short-term. I didn’t plan for this to happen, I’ve just found myself in these circumstances. There is no other beginning Yii 2 book out right now. So I did the best I could and I put a lot of effort into making Yii 2 as understandable for a beginning programmer as possible.
I realize that by being so into Yii 2, I no longer have objectivity to the other frameworks. That was bound to happen. I had to pick one. And when I get into something, I go all in.
So Yii 2 For Beginners is out now. I’m really glad I could contribute something to help beginners harness the potential of Yii 2, it really is an amazing framework.
Now that the book is done, I’m looking forward to getting back to application development, I hope to have a new site done in January. After that, I’m going on vacation, if I’m still breathing…
I will continue to support PHP and Yii 2 beginners on this blog, and hopefully continue with the polls, which people seem to find interesting. Over 1000 developers have voted in my polls. I hope to continue to develop this blog as a resource for the community.
I’d like to take a moment and welcome everyone who is finding their way to this blog. We have readers from all over the world. A lot of people have voted in the polls and the most active one is on my Yii 2 vs. Laravel post. Over 700 people have voted in that poll, so thank you to everyone who has participated.
Recently I read the book Clean Code by Robert Martin and it got me thinking about coding style and standards. I saw on the news release for Yii 2 that it follows the PSR standards, however I found some instances in using Yii 2, where it’s not following the standard.
For example, the naming of a private variable in the LoginForm model:
class LoginForm extends Model
public $rememberMe = true;
private $_user = false;
Accodring to the PSR-2 standard:
Property names SHOULD NOT be prefixed with a single underscore to indicate protected or private visibility.
Personally, I like the way Yii 2 is doing it there, it seems very intuitive to me and I couldn’t understand why the PSR standard would be against it. So I posted a question about in the Yii 2 forum and got an excellent response from forum member DocSolver. This is what he said:
“An argument in favour of the PSR-2 standard: if you change the status of a property from protected to public, you have to refactor all references to it.
The underscore in the name reminds me of to the old programmer’s habit of prefixing a variable’s type in its name (e.g. “floatAmount” and “strCustomerName”), which was popular in older languages when IDE’s were nonexistent. But now these habits are considered a bad practice by authorities such as Robert C Martin (see book “Clean Code”).
Because of this, I would say that your IDE should notify you about a variable being protected, instead of a naming convention that will probably be violated by many people. So I would vote in favour of conforming the Yii2 codebase to the PSR-2 way.”
DocSolver made some excellent points. But one thing to keep in mind is that the Clean Code book covers Java, which is a strongly typed language anyway, meaning that the variable type is explicitly stated with descriptors like string and int. So java gives you more hints going in.
Personally, I like the underscore because it pops out at you like a speed-bump. For example, in the code snippet above, it helps me understand that $_user is not from the form input, it really jumps out at you as different.
Anyway, this might be microscopic overkill on style, but I do feel standards are important and should be respected. One of the main points in the Martin book is that programmers spend much more time reading code than they actually spend coding. It’s so true. And that means things like this become important because it’s likely someone will have to read your code and the easier it is for them to understand it, the better.
I wrestled with this issue a bit because I would be much more comfortable using the underscore for private variables, just seems to have stuck in my head as a good way to go, but I’m going to sacrifice that peace of mind I get doing it that way to stick to the standard. I think following the standard is actually more important, at least in this case. Plus DocSolver made a pretty convincing case of why following the standard is actually better.
Internally, we can resist change, but that is just a form of inertia. I remember friends being resistant to the new array notation because they were so used to the old style, which to me looks like dinosaur code. I don’t want to be in the dinosaur camp.
I’m not a fan of mindlessly following what we think others expect from us. I think the controversy on TDD is an example of that. On the other hand, when programmers come together to set a standard, it’s worth taking it seriously.
In terms of Yii 2 projects, I will not be refactoring the framework code just for the sake of eliminating an underscore, that would silly. Plus, I would probably just mess it up anyway. I’ll just be mindful for my future code, when creating a private property, to keep it clean of the identifying mark. Let us know what you think. Take the poll and let us know if you follow the PSR-2 Standard.
The stable version of Yii 2 is officially released today and I thought I would mark the occasion by writing about it. I think the release of the framework is significant and it will impact PHP programmers for many years to come.
The more I learn about Yii 2, the more I like it. Even though it was only in alpha when I started learning it, and the documentation was incomplete, I was able to go much further on Yii 2 than other PHP frameworks like Symfony and Laravel. Not only could I see obvious benefits in the architecture of Yii 2, but Yii 2’s advanced template provided me with enough structure out of the box to get something started, and that something included mobile-first bootstrap design with a working user model.
Sometimes, all we need is to be able to follow a well-thought out implementation and the advanced template is certainly that. With just a little modification, I was able to create a custom, and I should say simple, access control for admin, roles, user types, etc. I was able to do it quickly, getting an application going in about week, which considering where I was as a programmer when I started, was pretty cool.
Yii 2 is just incredibly well-thought out. It seems like the dev team has anticipated just about everything you could ever think of and found a way to support it. The behaviors and event architecture is feature-rich and very intuitive. And then of course there is Gii, the amazing tool that cranks out code for you and saves you even more hours of work.
I think the biggest frustration anyone feels learning a framework is dealing with the sheer size of it. This is true of any of the big frameworks and also true of Yii 2. You can’t just snap your fingers and master it.
Yii 2 is like a Ferrari. You want to jump in and go and leave tire tracks, but first you have to take the time to learn how to drive. What a drag.
Maybe that’s not the best metaphor because it should be understood that it takes significant time reach a level with PHP that allows you to run at high-performance. Gone are the days when PHP was just a quickie scripting language that let you build a form for your webpage. What we have now is more like rocket science, or, and not to be comical, more and more like Java.
Anyway, Yii 2 has a huge code base. When you work your way in recursively, deep into the framework, you find yourself in strange territory quickly. And I guess that’s what makes the surface so amazing. The deep wizardry is extracted to base classes that allow us to have these nice intuitive methods to work with.
I’ve documented hundreds of pages of work in Yii 2, so much so, I may even write a book for beginners on it. If you really want to learn something, try writing a book about it. It’s a very exhausting, yet effective technique.
And yet, for all that work, meticulously documenting controller methods, models, view architecture, and form models, etc., I still find it hard to explain exactly which features make me like Yii 2 so much. And I think the reason for this is a non-programming term: flow. Yii 2 just seems to flow.
I tend to think in creative terms. If I have an idea, I want it to flow. I don’t want the idea to come up against endless barriers because that is what kills ideas. The extent to which Yii 2 helps my creativity flow is a measure of how much I love it. And I love it a lot. It’s driving me to learn this alien rocket science, so I can take the new rocket ship up and see what the world looks like from that orbit.
A new generation of programmers will do the same. They’ll take it to heights none of us have ever seen before. PHP is in fact alive and well and flourishing in Yii 2. Check out the poll results in some of my other blog entries and you’ll see what I mean. I find this all very exciting.
Anyway, I’ll conclude by congratulating Qiang Xue, Samdark, Cebe, and the other dev team members for reaching such a great milestone. They made something really special. If I could say I only know one thing about programming, it would be this: it ain’t easy. So, great job guys and congrats again.
Recently I began wondering if PHP was still a relevant language, considering that so much focus is on mobile and that would point towards Java and Objective C. Also, I’ve recently begun investing a lot of time into learning the Yii 2 PHP framework, which I think is awesome. Now awesome might not be considered a technical term, but I have to tell you, I don’t mind expressing my passion for something. I’m a human first, engineer second.
I’m always looking to expand my education and the lack of new books on PHP worried me. Was I wasting my precious time on a dead language? It’s only when I looked for material on PHP frameworks, that I found a bunch of titles. There were certainly a lot of Laravel books. One thing that impressed me about Laravel is that they really tried to impement the ideas expressed in Robert C. Martin’s book, Clean Code. Laravel has lots of pretty, semantically pleasing code. So I played around with Laravel, but I didn’t feel it was quite at the level of Yii, and I just happened to be researching this when Yii 2 Beta came out. I tried Yii 2 beta and fell in love with it, especially the advanced application template. It gets you up and running with a mobile first Bootstrap impelmentation, with a working user registration model for both frontend and backend, right out of the box.
Books on Yii 2 are as of this writing, not out yet, but they are coming. I think they will help usher in a new generation of PHP programmers who will take it to new a new level. Applications will be built faster, with a more robust and extensible infrastructure. As of this writing the general release for Yii 2 is about 30 days away.
So there is a lot to be excited about, but getitng back to the original question here, “Is PHP still relevant?”, I can’t help but wonder if it will be overshadowed, either by another language such as Ruby or by a mass migration off the web via mobile. Of course the Internet wouldn’t disappear, but I could imagine websites as we know them being a relic of the past.
Anyway, I did some searching on Google and found this article on PHP which states that Google has determined that PHP is used on 75% of all websites. If true, that is certainly a compelling and calming statistic. PHP is widely adopted and used, even if it is not always the flavor of the month.
PHP does seem to have a lot of haters, and people who are into other languages such as Ruby are not shy about voicing negative opinions about PHP. A lot of the complaints about PHP seem to be rooted in ideas about what a language should be. It reminds me of the idealism I found in the Clean Code book.
Now I’m the first to admit, I’m not qualified enough in Java to review that book. My only exposure to Java is a single book I read on it by Richard M. Reese, when I was recovering from Gall Bladder surgery. Out with the gall bladder, in with Java.
Anway, I couldn’t help be impressed by the robustness of Java and how its best practices imply a strong architecture that guides a developer into following best practices. That’s the good news. On the other hand, it was my impression, from standing at the foot of the mountain, that it would take far more programming hours to do something in Java than it would in PHP.
Also, if PHP programmers tried to follow Clean Code principles too literally, they would bloat their code base with an unmanageable number of files. I mean unmanageable from a server standpoint, that much PHP would bog down the server. You could have extremely clean code and extremely bad server performance. Laravel for example, suffers from exactly these kind of problems.
You can solve those problems easily if you have enough money to throw at it. You can hire teams of Java developers who can build an elegant archictecture that supports maximum code reuse and extensibilty, if I can be so bold as to use that phrase. Or you could throw server resources at the problems and just feed the beast. The thing is, doing so will cost you a fortune, and most companies don’t operate with those kinds of budgets.
PHP is a low-cost alternative to that. So please don’t sneer at it, Mr. Investor, when a start-up tells you they are using PHP. The language, while not as robust as Java, has evolved, and become more object oriented in 5.4 than in previous versions, with namespaces, traits etc. Frameworks like Yii 2, which use PHP 5.4 and above, can help you do amazing things in a rapid development environment, with templating and code generation.
So here I am making the case for PHP, but I don’t really need to. The google stats speak for themselves. Wise, pragmatic programmers already know that PHP is still very relevant. This doesn’t say anything negative about other languages or frameworks. They all have their strong points. Liking one language is not a good reason to hate another.
And finally, looking into the crystal ball for the future, I will address the mobile issue. I think we will see more cross platform development, like Zend is doing with their Zend Studio product, which I should note, I do not use, so this is not an endorsement. But I do find interesting that you can build a front-end mobile app and have it be directly connected to your servers and your web architecture.
When I checked it out, I didn’t love the Zend PHP Framework, I didn’t find it intuitive or easy to use, so I’m not really following their IDE. But I do think we will see more products like this in the future and ultimately, PHP will be supported. After all, 75% adoption on the web is too much to ignore.
Vote in the poll at the top of the page about whether or not PHP is still relevant and let us know what you think.
In 2015, with the release of Laravel 5.1, I switched all of my php development onto Laravel. Although I started with Yii2, and wrote the Yii 2 for Beginners book, I have since focused solely on Laravel, and written 3 books on Laravel, the latest being Laravel 5.4 For Beginners.
I outlined the reasons for my switch in the following post. I had a great learning experience with Yii 2, for which I’m grateful, but I thought it was important to put this post in context.
I wrote this when I was a complete beginner as a programmer, in 2014. I’m leaving it up because it is part of my evolution as a writer and programmer.
The original post from 2014:
It was my job a couple of years ago to be a part of the team that decided what php framework my company was going to use. We did as much research as we could and boiled it down to a choice between Symfony 2 and Yii 1.1.14. We ultimately decided to go with Yii. It seemed more agile for our project and we felt the learning curve would be more acceptable. We did not regret our decision and we have been happy with the results.
Since we made that choice, I have followed the php frameworks to keep up on them. At the time we made our decision, Laravel was so new, we couldn’t seriously consider it, but it has grown quite a bit since it’s 4.1 release.
In fact it’s grown so much that Laravel has become the most popular php framework. There are some good reasons for this, including the fact that Taylor Otwell, the author of the framework, developed a very intuitive syntax that is very easy to understand, especially for beginners.
The Laravel framework is built on top of Symfony 2, a popular enterprise framework that is used for developing enterprise-level applications by many developement teams. Symfony 2 is a robust framework, but I found it to be overly complicated and bloated on resources. This makes Laravel even more bloated, since it’s layered on top of Symfony.
Although Symfony 2 has beautifully written documentation and an arhcitecture that aspires to be symphonic (pardon the pun), it comes with a steep learning curve, and I didn’t find reliable online tutorials/examples that would show me, for example, how to build a functioning user model. It was my frustration in trying to learn Symfony that led me to Laravel. Laravel seems to have more support, more books and a site called Laracasts.com that can get you up and running quickly.
Laravel is written very intuitively, using facades, which are a type of static method, making the code easy to follow. If I could get inside Taylor Otwell’s head, I could imagine that his framework started as a series of shortcuts for Symfony that made it easier to work with.
Sometimes working with a particular framework is simply a preference for style, since they are all powerful tools in the hands of masterful coders. I don’t wish to paint any of these frameworks in a negative light. Programmers, however, constantly have to make decisions and deciding what framework to use is one of the most important decisions to be made.
So now we’re ready to discuss Yii. I have to say that in comparison to Symfony 2 and Laravel 4.1, Yii 1.1.14 is just plain ugly. Very powerful and in some ways much easier to use, but not necessarily intuitive or easy to learn. They do have a very active and helpful community, but their documentation is typically lacking in sample code, a complaint I could make about all frameworks. Laravel seems to do better on that front, although they are far from complete in that sense.
But Yii is different in more meaningful ways. Both Symfony 2 and Laravel 4.1 embrace migrations to create database tables, which leads to a piecemeal approach to the data model. Imagine six different programmers are deciding what tables to create and what attributes (columns) should be in those tables. Though it’s a popular style of programming these days, it’s not in my opinion a best practice.
Database modeling should be a centralized and well-thought out task. It should be built before any programming is done, perhaps not entirely, but to the point where the project is well-formed before a single line of code is written. Relationships, foreign keys, indexes, etc. need to be part of a disciplined architecture, not subject to the whims of individual programmers.
Even in the case where a single programmer is building the project, they are better off doing the database work with MySql Workbench (assuming MySql is the db) than with migrations. For one thing, migrations might not enforce constraints on foreign keys correctly and you would not even be aware of the problem.
Ok, I could go on and on about DB modeling, but let’s get back to Yii. Yii has a browser-based code-generation tool, named Gii, that lets you build your models from the existing database tables. This allows you to develop the database inside of workbench first, then press a button later to generate the models based on your well-thought out DB design. Yii also supports migrations if you insist on creating your tables that way.
The code generation doesn’t stop with models, it also allows you to build an entire crud scaffold, with ready-made controllers and views. This means you can develop a basic application quickly, then focus on the things that make your application unique, the complicated stuff.
While Yii 1.1.14 was powerful, it wasn’t necessarily beautiful. Now some programmers will simply dismiss this as a cosmetic notion because after all, what does it matter? Well, the more cryptic the architecture, the slower people learn and the slower projects move, which is never a good thing. Also, there were some other problems, the most notable of which were the fact that they didn’t use composer for dependency management and didn’t use namespaces.
To their credit, the Yii team, led by founder Qiang Xue, listened to their community and with Yii 2.0 patiently built the most intuitive and full featured php framework I have ever seen. Imagine out of the box that you have a frontend, backend, a functioning user model with signup and forgot password functionality fully working. Imagine the framework uses Bootstrap 3 as its default css framwork. Can you believe you get mobile first design right out of the box? Well, no need to wonder, just download the advanced template and try it for yourself, you will be amazed at all the features and how fast you will move through it. Or I should say, just use composer to install it because it now uses composer to manage its dependencies and composer is really easy to use.
It’s hard to describe the beauty of the architecture, you just have to see it for yourself, but it is much more concise and intuitive than it was before. As of this post, Yii 2.0 is still in alpha, but the beta is coming quick. Not a lot of docs yet, but you can find what they have here: http://stuff.cebe.cc/yii2docs/guide-index.html. My bet is that you will be hearing a lot about Yii in the next year or so as it releases into production.
If you have a preference for one of the three frameworks in this post, please take our poll and feel free to sound off in the comments.