So what we’ve been focused on in the book is building a re-usable template that we can use as a starting point for our future applications. The advanced template that Yii 2 gives us out of the box is amazing, but we need to build on that because it only goes so far, as it should. After all, they really have no idea what kind of app you are interested in building.
I know for myself, I focus on the traditional needs of an application, and really at this point, the basics. This is because I’m treating the template as a stepping stone to bigger and better things, and when I focus on the more complicated and unique tasks, I don’t want to have to keep coming back to the basics. It’s best, in my view, to build a solid foundation first, then reach for the stars.
Also, I tend to think in terms of servicing a client. As I build my development skills with Yii 2, I ask myself, how will a particular implementation help a potential client?
For example, one task that a client will often ask of a web developer is that they want a response message sent through email, after a certain action occurs. It could be registration, sending in a support request, any of a number of things.
In fact, I’ve noticed that clients tend to change their minds a lot when it comes to these kinds of requirements. I don’t know about you, but that can drive me crazy. So what I try to do about it is anticipate the clients needs, to know what they will likely ask for before they ask for it.
Of course Yii 2 is a big help in this. The guys that have built the framework have thought of just about everything, and we’ll see how some of that plays out in a moment.
The other thing to keep in mind, is to look to the advanced template itself for best practices on how to do things. The Yii 2 advanced template comes with a contact form that sends an email. This form has a form model, and we can use that for part of the guidance we need to build our model. So you have some help from within the template, that makes things easier.
Getting back to anticipating clients needs. As I’ve said, and I’m sure you know this if you have worked with clients, they don’t always know what they want or when they want it, but when they do want it, they want it in a hurry.
So I tried to imagine with this code how I could write it in a way that would let the client manage it 100% from a UI in the backend. It’s fairly obvious why this is important, but in case it’s not, just imagine the following scenario:
The client calls you at midnight demanding that you change the text in the registration autoresponder. “The” in the third paragraph must be immediately replaced with “a” or all hell is going to break lose. They want you to stop everything, push a new version of the site, with that tiny update.
The client gets over-excited, yet at the same time, they are paying the bills, so we have to listen. It’s a nightmare. We’ve all been the there.
So I thought about how I could avoid that scenario completely. Wouldn’t it be great if they could just enter what they need into an admin page in the backend and never even bother to call me?
Ok, on one hand, when they call, we get paid, so we don’t want them to stop calling us. On the other hand, the more power we give them over their project, the more they will love us for the work we are doing and the more they will come back for more, especially an enthusiastic client who appreciates the attention to detail.
So obviously, if we were going to let the client update the text for the email via UI, we would most likely be storing that text in our DB. And we know writing that UI with Gii’s auto-generated code is a snap. So it’s not hard to imagine that part coming together quickly. We just need a simple data structure and that will work nicely.
What else would we need? Well, we need a model that looks up the record and fires off the email. And then here comes the buzz kill. How does it know which email to send and where do we put the code that calls the appropriate method?