info on high-level control flow of Rails?

rubyonrails-talk
1

I'd like to find some information on the high-level control flow of Rails. Currently, my understanding is that

  The request comes into the server.

  It gets routed to a controller.

  The appropriate view gets processed, using the appropriate   templates, etc.

This is a bit vague and mystical for my taste. Has someone written up a description of the principal methods that make all of this work? If so, I'd love to see it!

-r

2

-1

I'm quite familiar with the overall principles of MVC. What I'm looking for is a high-level description of the way that Rails implements its version of MVC.

-r

3

I put an overview on:

http://rtfm.calicowebdev.com/articles

I hope it's useful.

Steve

Rich Morin wrote:

4

I can't think of anything offhand - most of the information available is of a how-to nature rather than theoretical.

That is my impression, as well.

Have you looked at the Rolling with Ruby on Rails articles on the O'Reilly website?

Yes

It may be worth your while getting a copy of the Agile Web Development with Rails book and working through the tutorials.

I went through the tutorials in the first edition, a few months ago. I'm now most of the way through the tutorials in the second edition (which is greatly improved, IMHO).

I think this will give you a much better idea of how Rails works than any high-level overview.

Actually AWDwR provides very little information on the internal workings of Rails. It's mostly "put this here, put that there, and voila, it all works". This isn't bad, but it doesn't serve my need for information on HOW it all works.

Alternatively, you could re-post in the Rails core forum - you may get a more sensible answer there.

I'll consider that; thanks.

-r

5

Yes, it is, although I wish you would put up a "print- friendly" version. However, there's still a lot of "passive voice" being used, as:

  "Controller Code Invoked"

  "View Rendered"

What routines do the invocation and rendering? Who is responsible for bringing in layouts, etc? Like that...

-r

6

These aren't high-level questions at all. What routines invoke controllers? I don't think you'll ever need this, but you can trace the codepath quite easily in the Rails source to see that Dispatcher::dispatch determines the actual controller by running the request through the routing logic.

ActionController::process is the base class method that gets that name of the action (as it says in the comments) from the request parameters and then runs the corresponding action.

Rich Morin wrote:

7

It looks like public/dispatch.{cgi,fcgi,rb} are the first bits of Ruby code that get executed in Rails, depending on the execution environment. Is this the case?

If so, why might

  system('/usr/bin/touch /tmp/t1')

in them be failing to act?

Details:

  This is in a Locomotive environment on Mac OS X.

  % which touch   /usr/bin/touch

-r

8

I think what you need is chapter 2 of the "Ruby for Rails" book by David A. Black. I've been working on Rails for a while now however I just bought the book yesterday. I've been through the first chapter only and what a mistake I made by not reading this book before starting working with Rails. I think this should be the starting point for anyone starting Rails development.

Hope this helps.

9

The first thing that comes to mind is permissions.

Have you looked at your return code and system error logs?

Try touching something you know you have permissions to access for write.

Also:

ls -l / | grep tmp

and see who the owner is.

Rich Morin wrote:

10

/tmp (really, /private/tmp on Mac OS X) is mode rwxrwxrwxt (writable by anyone, but sticky). I'm trying to write into a file in it, as a way to check that some code is getting run. Perhaps I should use other tracing options, but this seemed the simplest (and least dependent on Rails, etc.)

-r