Comeback Contest
Check out our forums for the an explosive comeback contest. We are giving away everything from iPods to Visual Studio. more...
Check out our forums for the an explosive comeback contest. We are giving away everything from iPods to Visual Studio. more...
| Member List |
Webmaster Forum - Viper Creations / Programming / Ruby On Rails / What is ruby on rails and why am i seeing it everywhere?
Pages: 1
| Posted: 10 Apr 2007 14:49 | ||
|
Registered User Currently Offline |
Posts: 26 Join Date: Feb 2007 |
|
| .... | ||
| Posted: 16 Apr 2007 16:00 Last Edited By: nuvo | ||
|
Registered User Currently Offline |
Posts: 1 Join Date: Apr 2007 |
|
|
This reply is written at the request of Daniel Neri (which explains why it's my first post here).
Ruby is a highly object oriented programming (OOP) language that was created in Japan some time ago. Like PHP, it's an interpreted language, so you'd usually need to have the Ruby engine installed on the system you're running scripts on. The whole OOP thing is what gives Ruby many of it's advantages over languages like PHP, which are either lacking OOP abilities, or have them added later (like PHP5) as unlike those, Ruby uses objects almost everywhere, not just in a few places. Another neat feature is symbols. A symbol looks like a variable, but it's got a colon stuck to the front of it, so it'd look more like :var. Symbols help keep memory usage down as unlike strings, they don't create a new memory address each time they are used. A better explination can be found HERE. Basically, Ruby is a highly OOP based interpreted programming language that came from Japan, but is in English. It's been around for years, but has mostly been the reserve of *nix (Unix, Linux & similar) OS users as it's not compiled and scripting is more common under unix like systems (bash scripts, perl scripts, CRON jobs and such). Rails is a website development framework built with and on top of Ruby. What Rails does is to take much of the hassle out of web development by reducing the number of configuration you need to do and the amount of SQL database code you need to write. Rails' ActiveRecord makes building applications that will be deployed on many different database engine configurations easier as you don't have to use SQL code. You use something like: Code:
def list items = Item.find(:all) end In that example, you'd have a model for your items and you'd search your database of items through the model, so no SQL at all (Rails handles that for you). Then your variable (items) gets populated with your item data. The :all thing is a Ruby symbol, which is just telling it to get everything in the items table. You can do more complex stuff such as searching for items that meet a set of conditions by doing something like: Code: What we're doing here is:
@items = Item.find(:all, :conditions => ["type = ? AND quantity = ?", "Shoes", 125], :order => "id DESC") @items = Item.find: Use the Item model to search our "items" table and put the results into the @items variable (the "@" allows us to use the variable in a view, which we'll go into later). :all, :conditions => ["type = ? AND quantity = ?", "Shoes", 125]: Get all results that match our query. Our conditions bit works the same as "WHERE `type` = 'Shoes' AND `quantity` = 125"... The only difference is that doing it the Rails way helps combat the whole issue with people hacking your database due to how queries are written. Whenever you use a question mark, you then put in what you want to use in it's place after the condition code. :order => "id DESC": Does the same as ordering in mySQL and such. MVC: Rails is based on the Model View Controller way of developing applications, much like Djanngo (Python) and other frameworks. Models are used for database interaction and you'd usually have one per table in a Rails app. Models are what you call when working with the database in a hands off way (though you can use raw SQL code). You don't have to have much of anything in the model file, but it's generally a good idea to put all your database interaction code into them. Views are what the user gets in their browser. Almost no logic is used in these files usually as they are mostly there for the layout of your application when it's displayed to the end user. Controllers are where your application logic goes for the most part. Controllers are usually populated with actions, which are what you're actually linking to by going to site/this/that/. An URL in Rails breaks down into site.com/controller/action/variable, but this can be altered using the inbuilt routing set that Rails has. Using Rails' routing makes life easier as it's often easier than using Apache's mod_rewrite, though you may still need to use that for some things. My brain is currently farting on itself, but please feel free to ask about things and I'll see if I can provide an answer. If not, I'll scout around and see if I can come up with anything. |
||
| Posted: 16 Apr 2007 17:09 | ||
|
Administrator Currently Offline |
Posts: 156 Join Date: Oct 2006 |
|
Awesome Nuvo 
Thanks for the explanation __________________  |
||
| Posted: 17 Apr 2007 16:43 Last Edited By: tomharding | ||
|
Registered User Currently Offline |
Posts: 26 Join Date: Feb 2007 |
|
|
Yup.. thanks!
I think i'll pick up a book on that when I graduate. No use letting this awesome opportunity go to waste! Any books you can recommend? |
||
| Posted: 12 Feb 2008 03:32 | ||
|
Registered User Currently Offline |
Posts: 2 Join Date: Feb 2008 |
|
|
Nice,
I would like to look at Ruby alot more as well, I hear it has some neat javascript libraries built in. |
||
Pages: 1