So I’m wrapping up my first major Rails project here at the SHA. Overall the experience has been very positive, though we’re currently wrangling with the difficulty of deploying Rails apps via Passenger (hard than it sounds). This post isn’t about that, however. If I ignore the many hours we’ve spent trying to get our servers to work right with Rails, I would say I’m in love. Right now, it’s more like cautious optimism.
Rails has been a great experience in many ways, especially after working in CakePHP for so long. But there was one point in particular that made me really appreciate the thought in the framework, despite having to put in some extra work.
One of the final things I needed to add to my app was a simple Feedback form. Very standard. All it had to do was take a name, email and some comments and email them to the web administrator (me, in this case). If this was a standard PHP script, I would have written the form processing in the header of the form display page. If this had been CakePHP, I would have created a static page in the /views/pages directory, and put some form processing code in some generic controller.
Rails would have none of this.
Rails has no equivalent of Cake’s “static” page directory. Every view *must* have a related controller. The email itself also must have a view, and the email processing and prep had to be tied to a particular ActionMailer pseudo-model.
Initially, this was really annoying. In order to create a single feedback form I had to create four different files (a feedback form view, a feedback controller, a feedback mailer model, and an email view). So I went and created feedback_controller.rb, with a single function, send(). Then I went and created my ActionMailer model, feedback_mailer.rb, that also had a single function to send that email. The file, feedback.text.plain.erb served as my email view, and the file, send.html.erb, was my feedback form. The Feedback controller handled the data prep and verification, and then it passed the submitted, cleaned data to the Feedback Action Mailer, where it would then be emailed to the web master. Phew. The whole time I grumbled about how many single-use files I had to make, and how much simpler this process could be.
But then I realized that wasn’t the point.
What I had just done, in fact, *was* simple, or, to put it more accurately, *will* be simple to someone in the future who may need to modify this feedback form. Since Rails was so strict about the code structure and location, a future programmer will know that this email routine will have to have a named ActionMailer component and corresponding view. Because she knows that all views have to be tied to a controller, she will know that the feedback_controller will most logically control the flow of data to the form /views/feedback/send.html.erb. If I had just written the entire mailing routine in one script, it would have been entirely without constraints and in the style of however I was feeling that day. I may have commented it, but the structure of the code could only be understood a posteriori, not a priori.
It’s only over time that I began to understand this powerful aspect of Rails. The occasional speedbumps I face usually happen because I want to write bad code. Rails tries very hard to not let me do this. The enforcement of code structure is one of the most important aspects of this system, and will be one of the many benefits our shop will see down the road.
