I would like to be able to read Rails source code, but I think I can't really do it, because I don't know were to start and how different parts of the code are connected. For example, it's obvious what ActiveModel does and I can read the code, but I don't understand how a Rails app generally gets loaded and when exactly ActiveModel comes to play and which part of rails invokes it.
I'm not talking about this general stuff people say in manuals that first Rack gets loaded, then Rails is a rack app... No. I want something more detailed, so that I could actually look up every step in the code. So I guess some sort of chart explaining how rails app gets loaded and maybe a note to each of the subdir, saying where those files are used, what they do and where on the load chart they do load would be nice.
Any tips on that?
Rails follows a pretty traditional MVC (Model/View/Controller) design, which you can read up on.
If you'd like to get a good overview of how a request is processed by rails, this looks like a decent place to start:
http://betterexplained.com/articles/intermediate-rails-understanding-models-views-and-controllers/
Here's a more detailed article about how the Rails initializers and environment are loaded:
http://toolmantim.com/thoughts/environments_and_the_rails_initialisation_process
The link is broken, here is the same article on github.
https://github.com/toolmantim/toolmantim/blob/master/articles/environments_and_the_rails_initialisation_process.haml
It's not yet complete, but this series of articles, Rails from Request to Response by Andrew Berls helped me:
Introduction
Routing
ActionController
Related
I am completely new on Ruby On Rails and I already watched a long tutorial to start developing a small web application. In such a tutorial I could see several helpers for textboxes, textareas, dates, times, checkboxes, radiobuttons, comboboxes, and so on.
Where can I find other helpers like accordions, WYSIWYG editors (like an HTML editor), and others that can be bound to data from model and used in views? Maybe a toolbox for example.
I will very much appreciate your feedback.
Best regards.
What you're mostly talking about are Form Helpers. There are a bunch of other Rails Guides so I'd recommend reading through them and getting a better idea of what Rails does and can provide.
If you're not finding what you need in that documentation, you may need to add a 3rd party gem to your app's Gemfile, and follow the gem's documentation for getting it working. The Ruby Toolbox is a good place to start searching if you want to see which gems are most common.
And, of course, in the end you might not be able to find something that someone else already wrote and that solves your problem, in which case you will need to write it yourself. For front-end stuff you'll want to get up to speed on how to use HTML, CSS, and Javascript.
Looking at the Readme of the Journey Router (which is the Rails 4.0 router), it is rather empty. I was wondering how the router works conceptually, and if this 'abstract' grammer is catching the idea, of the router as mini-programming-language:
ROUTE := GET|POST|PUT|DELETE path
path := (static_path) | (dynamic_path)
So, how does the Rails 4.0 Router work?
If you want to understand Rails routing, the best place to start is Rails Routing from the Outside In in the edge guide.
After that, you'll have more luck looking at ActionDispatch::Routing's docs.
Note: The following relates to Journey v1.0.4, which was the latest at time of writing.
Journey itself is the Rails routing engine introduced in Rails 3.2. In the release notes, it is described with a single statement: "Route recognition also got a bunch faster thanks to the new Journey engine." That's not a lot of info specifically about Journey, of course, but Rails doesn't describe every implementation detail; that would take forever! :) Journey's gemspec also describes itself with the statement: "Journey is a router. It routes requests."
You could look at the api docs, but in v1.0.4, it has extremely sparse documentation (Journey::Router::Utils.normalize_path(path) is documented) other than the code itself and maybe its open and closed issues. You could take a look at the other S.O. posts with tag journey.
Some of the code is somewhat self-descriptive just via method names, etc. like in Journey::Routes. Journey's tests are also a great way to see how it works.
Some notes on the code itself:
It monkey-patches Hash in pre-1.9 versions of Ruby to add a keep_if method.
"gtg" stands for "generalized transition graph" (see here)
Funniest code is here (Easter egg: rails c then Journey::Path::Pattern.new(9))
Journey's visualizer might be interesting to play around with, also (note visualizer method in Journey::GTG::TransitionTable). Sample visualization here, and online demo here for now.
I'm coming from C#, and recently I started to write some Ruby on Rails applications.
My biggest problem with it is the documentation because I find it extremly difficult to use. For example, finding out how to call generator from my controller took me about 2 hours and then 15 minutes after that I found Rails::Generators.invoke method to figure out what arguments should I pass to this function.
Maybe I use the documentation the wrong way; First I take a wild guess and search in the Netbeans code completion, which is rarely helpful, then I search in Google, then go with the API.
Can some experienced Rails programmer give me some advice?
If you're new to rails I recommend you read a book before you dive into the API documentation.
Here are two recommendations:
Agile Web Development With Rails - Great introduction and reference on how to use rails.
Programming Ruby 1.9: The Pragmatic Programmers' Guide - More on Ruby. Great references!
After you've worked your way through those books, you'll have an idea of how Rails is designed and where to look for stuff.
Both books are great reference books. If you want to access the Rails and Ruby API's online, make sure to checkout RailsApi.com
I am describing my own very personal workflow with Ruby/Rails documentation:
You can use ri and rdoc if you are familiar with the console, but...
Personally, I recommend two very good Ruby/Rails documentation sites:
apidock.com (no good search, but sometimes fine examples)
railsapi.com (very good AJAX search, plus you can customize what documentation you would like to see - by versions and by Gems)
Every iteration of the Rails guides (http://guides.rubyonrails.org/) has a ton of useful stuff in it. That should be the first stop.
After that I search away in the API - http://api.rubyonrails.org.
Sometimes I even end up just reading the source code trying to find things - https://github.com/rails/rails.
I think the best place in the source code to be reading is in here - https://github.com/rails/rails/tree/master/railties/lib/rails.
I upvoted each of the other answers here.
I just started to document a rails application. I know this is actually done by rdoc, so I followed some rdoc guides regarding syntax and so on, but I got stuck when I tried to describe attributes of models, validations and the relationship between models, mostly because these things are part of ActiveRecord. So I wonder if there is some guide or a good practice regarding how to document a rails application or if there is something I'm missing?
I know that I could put all of this in the class description, but I wonder if there is a way more closely tied to the declaration itself (has_many, validates_presence_of, etc.) and what about the attributes?
I personally prefer YARD - http://yardoc.org , as it does a better job in documenting IMHO.
I don't know if there's a specific handler for Rails available, but it's quite easy to write one - http://yardoc.org/guides/extending-yard/writing-handlers.html
A good example might be the attribute handler - part of the yard gem:
lib/yard/handlers/ruby/attribute_handler.rb
Remember your tests are part of the documentation (for developers), particularly if you are using Cucumber where scenarios are easy to read. If you keep your methods very short and there is a test method with a descriptive name e.g. "should set the users name" I find I typically don't need comments on the method.
Validations or other parts of Rails I would not document. Part of being a Rails developer is understanding how these work, I think it is a fair assumption that another maintainer of your code reading it down the road will know validations, or other things built in to Rails. By that same logic, if you can use features of the framework or happy paths (not deviate much) with [documented] third party code, a lot of the documentation will be written for you.
Some background:
I'm a jack-of-all trades, one of which is programming. I learned VB6 through Excel and PHP for creating websites and so far it's worked out just fine for me. I'm not CS major or even mathematically inclined - logic is what interests me.
Current status:
I'm willing to learn new and more powerful languages; my first foray into such a route is learning Ruby. I went to the main Ruby website and did the interactive intro. (by the way, I'm currently getting redirected to google.com when I try the link...it's happening to other websites as well...is my computer infected?)
I liked what I learned and wanted to get started using Ruby to create websites. I downloaded InstantRails and installed it; everything so far has been fine - the program starts up just fine, and I can test some Ruby code in the console. However my troubles begin when I try and view a web page with Ruby code present.
Lastly, my problem:
As in PHP, I can browse to the .php file directly and through using PHP tags and some simple 'echo' statements I can be on my way in making dynamic web pages. However with the InstantRails app working, accessing a .rb or .rhtml page doesn't produce similar results. I made a simple text file named 'test.rb' and put basic HTML tags in there (html, head, body) and the Ruby tags <%= and %> with some ruby code inside. The web page actually shows the tags and the code - as if it's all just plain HTML. I take it Ruby isn't parsing the page before it is displayed to the user, but this is where my lack of understanding of the Ruby environment stops me short. Where do I go from here?
AMMENDMENT: This tutorial has helped me immensely! I'd suggest anyone who's in my position go there.
First of all, you must disconnect the relationship between files and URLs.
Rails uses an MVC approach, which is worlds-different from scripts-based approach like ASP/PHP
In classic PHP, you have something like this
Server> Server started, serving scripts from /usr/jake/example.com/htdocs/
User> Please give me /home.php, thanks!
Server> OK, /home.php is mapped to /usr/jake/example.com/htdocs/home.php
Server> Executing /usr/jake/example.com/htdocs/home.php
Server> OK, it prints out a "Hello World!", send that to the response.
User> Ok, /home.php shows "Hello World!"
However, most MVC framework (Rails included) goes something like this:
Server> Server started, initializing routing modules routes.rb
User> Please give me /home, thanks!
Server> OK, /home, per the routing module, is handled with action ShowHomepage() in controller FrontpageCtr
Server> Execute FrontPageCtr.ShowHomepage()
Ruby> FrontPageCtr.ShowHomepage() prints "Hello World!"
Server> OK, sending "Hello World!" down the pipes!
User> Ok, /home shows "Hello World!"
As you can see, there is no connection between what the user put into the addressbar and any script files
In a typical MVC framework, processing a request for any URL goes something like this:
Look in the Routing module (which in the case of rails is defined in routes.rb)
Routing module will then tells the server which "Controller" and "Action" should be used to handle the request.
Rails then creates the Controller and invokes the Action function whatever that might be
The result from the action then gets "Rendered", which, in this case, is supposedly rendering the .rhtml file as actual HTML... there are, of course, other kinds of results e.g. send the user to another URL and whatnot.
The result is then written out to the response stream and displayed by the user's browser.
In short: You must disconnect the notion of scripts and URL first. When you're building MVC websites, they are almost always NOT related in a way that most people understand.
With that in mind, you should be more comfortable learning Rails and MVC way of life.
I'm not a Rails pro so please correct me if I'm mistaken on any part.
I would suggest buying and working your way through Agile Web Development with Rails, an excellent book and a very practical way to learn both Ruby and Rails. It's available instantly in a variety of electronic formats, plus you can get paper copy if you prefer that.
From what you describe you have a fundamentally flawed understanding of how Ruby and Rails, in particular, works. I suggest you spend some time with the book then come back and ask about anything that you get stumped on.
Rails is "parsing the page before it is displayed to the user", if you locate the right file to modify ;-) Those files to be modified are under the following folder(s):
app/views/...
That's the short answer. For a comprehensive one (for a newbie), I highly recommend: http://guides.rubyonrails.org/getting_started.html
Getting started with Ruby on Rails is something that is a little daunting at first, but after you get started it gets a lot easier. After running Ruby on Rails bootcamps for Startup Accelerators, Harvard Business School, in Times Square, Boston, and Pittsburgh, I started http://www.firehoseonline.com. It's a video tutorial to get started, so you should check out that site.
My advice is to learn as much as you can by actually writing the code. Don't get caught up too much in the details and the specifics. If a tutorial gives you some code to write, and some information, and you don't absorb all the information at first, keep going. Afterwards go back to the material, and once you have gone through the whole process of writing your first application a lot of the pieces will fit together.
As far as your question about opening the php files directly, using the MVC pattern is a little different. You need to setup a the controller, the views and the routes before you can start putting code into .rhtml (or now .html.erb) files. Because of this architecture you'll be able to write a lot of awesome, clean code, super fast, but it can be a bit tricky to wrap your head around (if you REALLY want to write code that way you can with other frameworks, but trust us that this way is better). Stick with it!
Keep your coding mojo high!
Aloha,
Ken