contents/articles/22.html
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 |
----- title: "Ten minutes on Rails (while eating Cake)" content-type: article timestamp: 1146317340 tags: "cakephp|rails|webdevelopment" ----- <p>Today I decided to do something different, something I've been dying to do since before coming across CakePHP: give Rails a <em>proper</em> try. Like many other <span class="caps">PHP</span> developers out there, when <a href="http://www.rubyonrails.org">Ruby on Rails</a> came out I felt damn jealous and terribly tempted to learn Ruby <em>only</em> to start using such an amazing web development framework. At the time I actually even started reading various tutorials about it, and I was literally amazed at how RoR revolutioned the way of developing web applications.</p> <p style="float:left;"><img src="/images/pictures/rails.gif" alt="" /></p> <p>One of the main problems which made me – sadly – abandon Rails was Ruby itself: personally I've never seen a programming language with a cleaner and more elegant syntax, but also – at least at the time – there weren't many hosts supporting it. LuckilyI found CakePHP quickly after that…<br /> Now however, more and more hosting companies boast full Rails support, and so when recently I <a href="/articles/21/">had to move</a> to a new host, I made sure it was Rails-friendly, <em>just in case I wanted to give Rails another try, someday</em>.<br /> Oh well, the temptation was so strong that today, only a two days after switching to my new host, I felt I <em>had</em> to try it, I <em>had</em> to taste something different than the usual Cake. </p> <p>I decided to (re-)read and follow the <a href="http://www.onlamp.com/pub/a/onlamp/2005/01/20/rails.html">OnLamp tutorial</a> about RoR, step by step, once again. I quickly typed <code>rails cookbook</code> from my shell and voilá, rails silently creates the skeleton of my application:</p> <p><span class="caps">README</span><br /> Rakefile<br /> app/<br /> components/<br /> config/<br /> db/<br /> doc/<br /> favicon.ico<br /> index.html<br /> lib/<br /> log/<br /> public/<br /> script/<br /> structure.txt<br /> test/<br /> tmp/<br /> vendor/</p> <p>That's familiar: it's very similar to what CakePHP's directory structure used to look like. Now Cake <em>evolved</em> and adopted its own schema, which – I must say – seems more functional than RoR's, at least at a first glance:</p> <ul> <li>app/ <ul> <li>config/</li> <li>controllers/</li> <li>models/</li> <li>plugins/</li> <li>tmp/</li> <li>vendors/</li> <li>views/</li> <li>webroot/</li> </ul> </li> <li>cake/ <ul> <li>config/</li> <li>docs/</li> <li>libs/</li> </ul> </li> <li>vendors/</li> </ul> <p style="float:right;"><img src="/images/pictures/cakephp.png" alt="" /></p> <p>Cake felt the necessity to divide what you can mess with (<code>app/</code>, <code>vendors/</code>) from what you'd better not touch (<code>cake/</code>). Rails just left everything on the same level.</p> <p>After creating my database and the necessary tables I have to edit <code>config/database.yml</code>, which corresponds to Cake's <code>app/config/database.php</code>. Then things start to become a bit different from Cake, as Rails offers some very handy built in scripts which can be used to automatically create your application's files, i.e. executing <code>ruby script/generate controller Recipe</code> creates the controller and other bits:</p> <pre><code>exists app/controllers/ exists app/helpers/ create app/views/recipe exists test/functional/ create app/controllers/recipe_controller.rb create test/functional/recipe_controller_test.rb create app/helpers/recipe_helper.rb</code></pre> <p>And so on. Anyhow… I followed the tutorial and yes, it was a nice read. CakePHP borrowed a lot from Rails but not everything. Inevitably Ruby's syntax is less verbose and looks very very clean:</p> <p><% highlight :ruby do %><br /> class RecipeController < ApplicationController<br /> scaffold :recipe</p> <p>def list<br /> @recipes = Recipe.find_all<br /> end</p> <p>def edit<br /> <code>recipe = Recipe.find(</code>params[“id”])<br /> @categories = Category.find_all<br /> end<br /> end<br /> <% end %> </p> <p>While CakePHP's, simply because it uses <span class="caps">PHP</span> and not Ruby, looks less pretty:</p> <p><% highlight :php do %><br /> class RecipesController extends AppController<br /> {<br /> var $scaffold;</p> <p>function list()<br /> {<br /> $this→set(‘recipes', $this→Recipe→findAll());<br /> }</p> <p>function edit($id)<br /> {<br /> $this→set(‘recipe', $this→Recipe→find(“id = $id”));<br /> $this→set(‘categories', $this→Category→findAll());<br /> }</p> <p>}<br /> <% end %></p> <p>CakePHP Development Team did a great job translating some of Rails functionalities into <span class="caps">PHP</span>, and the while CakePHP's syntax is <strong>much</strong> cleaner if compared to PHP's standard spaghetti-code approach, Ruby just looks much more clear, sorry. <em>Imagine a world without funny unnecessary brackets, pointless semicolons and where everything just looks better</em>: that's Ruby. </p> <p>Sigh. Now I do understand why Rails was built in Ruby and not in <span class="caps">PHP</span>: simply because a PHP's Rails would have been outscored by its “Ruby port”!</p> <p>One thing I liked about Rails which has not been ported in Cake (yet) is a somehow smarter way of scaffolding. While the Ruby code above actually works, the CakePHP's edit method doesn't, or better, it does but not as expected: when you remove <code>var $scaffold</code> the scaffold is just plain gone, and you have to code everything yourself, while in Ruby you can leave the scaffold and then develop methods one by one, and still be able to use scaffolded methods if you didn't define the custom ones.</p> <p>The other thing I noticed about RoR is that it definitely handles errors better! This is probably another language issue. I basically forgot to set a category for the recipes, and when executing my custom list of recipes I got a very, very well structured error page showing something like:</p> <p><% highlight :ruby do %><br /> NoMethodError in Recipe#index</p> <p>Showing app/views/recipe/index.rhtml where line #18 raised:</p> <p>You have a nil object when you didn't expect it!<br /> The error occured while evaluating nil.name</p> <p>Extracted source (around line #18):</p> <p>15: <% @recipes.each do |recipe| <span>><br /> 16: <tr><br /> 17: <td><</span>= link_to recipe.title, :action => “show”, :id => recipe.id <span>> </td><br /> 18: <td><</span>= recipe.category.name <span>></td><br /> 19: <td><</span>= recipe.date <span>></td><br /> 20: </tr><br /> 21: <</span> end <span>><br /> <</span> end %></p> <p>I took a screenshot of the page, because it was too nice: <a href="/images/pictures/rails_error.jpg">check it out</a>. This error page really tells you what's wrong, and even prints the lines of code around the error! It also lets the developer check the full backtrace and every sort of information… Can we have this in CakePHP please? I actually started to develop something like this, but seemed quite hard to do in <span class="caps">PHP</span>.</p> |