Posts tagged as:

controllers

I just read the article by Pratik Naik from the Rails Core Team regarding Rails Templates.

Have you ever wished you could start out your Rails application with all of your gems installed and all of your standard setup items completed? Well, wait no longer. You can now do it with Rails Templates. Pratik covered it pretty well, so I’m not going to repeat what he’s done. Rather, I’m going to share a template of my own and explain why I included what I did.

[click to continue…]

{ 1 comment }

One problem that seems to face people when they’re attempting to move their applications into production is the best way to manage deployment of their application. This is where tools like capistrano comes in.

Capistrano was written by Jamis Buck of 37signals. In a lot of ways it has become the defacto way to deploy Ruby on Rails applications. It has also had tools like webistrano build on top of it to provide a graphical interface to the command line tool.

To get started, you need to install the capistrano gem:

gem install capistrano

[click to continue…]

{ 6 comments }

While looking at articles and resources about authentication in Ruby on Rails I ran across a set of generators written by Ryan Bates of Railscasts. You can find the nifty generators at http://github.com/ryanb/nifty-generators/tree/master

I ran the generators and have posted the resulting code at http://github.com/charlesmaxwood/nifty/tree/master.

[click to continue…]

{ 5 comments }

I’ve recently seen several requests come through from people trying to figure out how to call controller methods from their views. The answer is pretty simple. Your controller instance, which is calling your view is stored in the instance variable @controller. So, calling public methods is as simple as this:

@controller.public_method

To call a private method you can do this:

@controller.send("private_method", args)

You should note that if you’re calling controller methods frequently in your views, you should consider putting them into helpers to make them available that way. If you need to manipulate or manage some data, the controller is the place to access the models for this, not the views.

{ 15 comments }

Have you ever wished you could mix Rack or Sinatra into your Ruby on Rails application just to get its raw throughput on certain parts of your application?

Let’s face it, sometimes, the Rails framework is overkill when we’re returning a simple string or an object in JSON as our response. Your answer for these instances is here. Rails Metal.

Performance

Some people have reported huge speed increases in Rails Metal over the Rails MVC framework. This article claimed a 25x increase over Rails. Pratik Naik from the Rails Core team benchmarked a more believable increase of 4x. Whatever the case, the performance advantage is worth noting.
[click to continue…]

{ 5 comments }

When I started writing part II, I started writing about models. As I got a little further along, I realized that it would be more helpful to provide an overview of the controller, which provides the data that goes into your web page, before I showed you how to get the data out of the database. My hope is that you’ll read this thinking of how you want the data provided, which adds context to part III on models.

Controllers are Where the Work Gets Done

Have you ever worked with one of those people who knows exactly where to go to get everything he needs. Can delegate his tasks effortlessly, and then pull it all together in the end. That guy would be our controller. When your website’s user browses to the page, the Rails engine picks up the request and decides which controller to send it to. More specifically, it decides which method in the controller to send it to. The methods on the controller are referred to as actions.
[click to continue…]

{ 0 comments }