Couldn't find any compiled info on new things in rails 3. Nor release date.
From http://mcphersonz.wordpress.com/2009/05/13/key-features-for-rails-v2-2-rails-v2-3-and-the-upcoming-rails-v3-0/
Lock up all the unicorns. You can’t please everyone all the time, so don’t focus on the unicorns.
No holy cows. Nothing is sacred in rails & everything is up for debate. Don’t look any anything we have & feel like that is the way it has to be.
Major Themes:
New routes. Faster, route by subdomain, user agents, etc. Rack to other rack machinery.
XSS protection (cross side injection). By default all output in views will be escaped. No more use of <%= h something %>. Assumed by default.
Javascript goes Unobtrusive & Agnostic. Much less JS is injected into page & instead unobtrusive JS is used to achieve same effect.
More Agnosticism.
Action ORM is a slim proxy wrapper for ORM tools that allows for easy swapping of ORM implementation,
Generators (script/generator) will for example allow you to specify that rspec is used, so script/generate model will create a rspec test file for model.
Refactoring
Abstract Controller takes similarities between for example ActionController & ActionMailer and combines them into one code base.
Cherry picking from ActiveSupport allowing you to pick parts that are used instead of pulling in the entire library.
Increased performance / speed with callbacks.
Related
I'd love to dive deeper into Ruby On Rails so I can understand the magics behind it.
For this, I'd like to examine all main components (gems) of Rails one by one, e.g. ActionPack, ActiveResource, etc. For this I'd love to have a list with the main components with short explanations (I will add more explanations step by step when learning about the gems).
Feel free to edit my answer with supplementary details.
Following are the Basic rail components with their short discription::
Active Support is a compatibility library including methods that aren't necessarily specific to Rails. You'll see ActiveSupport used by non-Rails libraries because it contains such a lot of useful baseline functionality. ActiveSupport includes methods like how Rails changes words from single to plural, or CamelCase to snake_case. It also includes significantly better time and date support than the Ruby standard library.
Active Model hooks into features of your models that aren't really about the database - for instance, if you want a URL for a given model, ActiveModel helps you there. It's a thin wrapper around many different ActiveModel implementations to tell Rails how to use them. Most commonly, ActiveModel implementations are ORMs (see ActiveRecord, below), but they can also use non-relational storage like MongoDB, Redis, Memcached or even just local machine memory.
Active Record is an Object-Relational Mapper (ORM). That means that it maps between Ruby objects and tables in a SQL database. When you query from or write to the SQL 19database in Rails, you do it through ActiveRecord.
ActiveRecord also implements ActiveModel. ActiveRecord supports MySQL and SQLite, plus JDBC, Oracle, PostgreSQL and many others.
Action Pack does routing - the mapping of an incoming URL to a controller and action in Rails. It also sets up your controllers and views, and shepherds a request through its controller action and then through rendering the view. For some of it, ActionPack uses Rack. The template rendering itself is done through an external gem like Erubis for .erb templates, or Haml for .haml templates. ActionPack also handles action- or view-centered functionality like view caching.
Action Mailer is used to send out email, especially email based on templates. It works a lot like you'd hope Rails email would, with controllers, actions and "views" - which for email are text- based templates, not regular web-page templates.
Action View is a framework for handling view template lookup and rendering, and provides view helpers that assist when building HTML forms, Atom feeds and more. Template formats that Action View handles are ERB (embedded Ruby, typically used to inline short Ruby snippets inside HTML), and XML Builder.
Action Resource (ARes) connects business objects and Representational State Transfer (REST) web services. It implements object-relational mapping for REST web services to provide transparent proxying capabilities between a client (ActiveResource) and a RESTful service (which is provided by Simply RESTful routing in ActionController::Resources).
Hypothetical question (at the moment!)
Suppose I have a great idea for an application. It acts on data which can be well-represented by tables in a relational database, using interlinked objects which represent those tables. It supports a well-defined API for interacting with (Creating, Reading, Updating, Deleting) those objects, and viewing information about them.
In short, it's a perfect fit for Rails... except it doesn't want to be a web-app. Perhaps it wants a Command Line interface; or an OS-native dialog-based interface; or perhaps it wants to present itself as a resource to other apps. Whatever - it just isn't designed to present itself over HTTP.
These questions suggest it's certainly possible, but both approach the problem from the point of view of adapting an existing web-app to have an additional, non-web, interface.
I'm interested in knowing what the best way to create such an app would be. Would you be best to rails new non_web_app, in order to get the skeleton built "for free", then write some "normal" Ruby code that requires config/environment - but then you have a lot of web-centric cruft that you don't need? Or would it be better to roll up your sleeves and build it from whole cloth, taking just the libraries you need and manually writing any required configuration?
If the latter, what exactly is needed to make a Rails app, but without the web bits?
If you want to access the Rails ORM to develop a CRUD non-web application, just include ActiveRecord in your own Ruby script; you will avoid using a lot of Rails modules you probably don't need (routing, template generator, ...) Here is an example of how to do it.
If you prefer to have the full Rails stack, do not run your Rails web app in an application server (WEBrick, Passenger, Mongrel, ...) to avoid any HTTP exposure, and interact with your application using tasks or the rails console.
I would avoid taking Rails too far off the rails. If I were doing this and felt that the gains of rails w/o the web stuff I'd do the following:
rails new non_web_app
and ignore the webbish cruft and use rails to generate models. In this way you get the tight, comfortable database behavior and can tie various gems in as you want to augment those models. I'd not bother implementing views, of course, and I'd consider implementing controllers in which the various render bits are removed and to use you instantiate an instance of the controller and call the action directly. This means the controller represents your API into your business logic still but the "views" it now "renders" are simply the return of the data output.
Then you could simply strip out the bits you do not need...the public directory, the view structure under app, config/routes.rb, etc. You'll need to test those changes incrementally and make sure that removing some now extraneous bit doesn't throw the Rails world into chaos.
Rails is for Web apps. That means HTTP. Now, you could package a Web app so that it runs on the desktop instead, or you could use ActiveRecord with a desktop application framework like Monkeybars.
In Rails we have both generators and templates to quickly setup and configure applications. Superficially, there seems to be 2 differences between generators and templates:
You can apply templates when creating a new application with rails new appname -m path/to/template.rb. Generators must be run after the creation of a rails app with rails g generator_name
Generators are classes made up of a series of public methods that are fired in the sequence they are declared. Templates are just a set of commands.
To my mind, this seems to make both generators and templates essentially identical. If I had to choose, I would go with templates because firing a series of public methods in the order they are declared seems to be quite a weird OO abstraction to me. A series of simple commands is far clearer and doesn't require the reader to know that rather unusual convention in order to understand templates.
Are there any more significant differences between generators and templates? If so, are there situations where one is more suitable than another? If not, why does Rails have both and is one method likely to become deprecated at some point?
I think it's mainly a chicken and egg thing that your are describing - the template you are describing (not to be confused with the templates of action view) has to be applied before the app is created, whereas generators do work from within the rails app (and more can be added via plugins etc). Apples and Oranges.
Will Rails 3 be a modular framework like Merb or Ramaze?
By this I mean, can we use any persistence framework (DataMapper or Sequel) and jQuery in Rails 3 application (via the command line for example)?
Or the default stack (ActiveRecord, Prototype) is still enforced?
(Sorry, I'm pretty new to Ruby/Rails community).
Thanks.
Rails 3 is much more modular than previous versions. Although it still defaults to ActiveRecord and Prototype, it has an ActiveModel API which means that ActiveRecord can be swapped out for a compatible ORM that implements the API.
Rails 3 also embraces the principles of Unobtrusive JavaScript and to this end the view helpers no longer output inline JavaScript mixed up with HTML. Instead, HTML5 data attributes are used and there are Prototype and jQuery "drivers" for hooking into those and adding behaviour to elements.
The whole ActionController stack is also much more modular enabling you to cherry pick just the parts you need and the common (non-HTTP specific) controller functionality is now shared by ActionMailer too.
Rails merged with Merb in late 2008 and the result is Rails 3
http://yehudakatz.com/2008/12/23/rails-and-merb-merge/
http://weblog.rubyonrails.org/2008/12/23/merb-gets-merged-into-rails-3
I've been using online tutorials to learn ROR. I've used www.lynda.com video lessons to get a basic idea what Rails is all about, and for practice I used Rails version 2.0.2, during my training period. But now I'm into a development team in a starter company where there are no senior/experienced programmers to assist me and we're working on gitorious source code modification using Rails 2.3.8. I'm facing a lot of difficulties to understand the source code and some of the major differences I could notice is as follows:
Inclusion of XML and HTML to render views in scaffolds, in Rails 2.3.8(I don't understand what this is, as I'd never come across this during my training period using Rails 2.0.2)
In gitorious source directory, in addition to Controllers, Models, Views and Helpers there are two more directories namely, Processors and Metals. I don't understand what their significance is.
Extensive usage of .yml files. What are those for? In rails 2.0.2, all I came across was the database.yml. Now, in gitorious, I see gitorious.yml. How are all these so customized? I mean, how do rails app(controllers, models, etc..) communicate with gitorious.yml?
With respect to all these questions, how do I move a level or two up, to call myself an "intermediate Rails programmer" from "Rails novice programmer"? and how do I stay updated of new api, deprecations, in all upcoming Rails transitions?
Inclusion of XML and HTML to render views in scaffolds, in Rails 2.3.8
Yes, the way scaffolding works has changed - I can't remember exactly when it changed, but I can certainly believe the change happened between 2.0 and 2.3.
When you generated a scaffold the old way, it would just include 'scaffold' commands in the controller, which would render up a default interface for each of the actions until you replaced them with your own HTML templates.
The new way actually generates the HTML templates as files: so, in the views directory, there will be a directory containing ERb (HTML with embedded Ruby). You can then go and edit those directly.
It also renders XML - this is done by default, but you can choose what other formats are produced. Rails lets you produce multiple output formats for each controller action - so that you can easily produce RESTful web services. So, you obviously produce XML by default, but you may want to produce machine other formats too: XML (including RSS/Atom), JSON (and JSON-P etc.), RDF, YAML. I use this to produce CSV and Excel so users of the site can get data exported to their spreadsheet package.
In gitorious source directory, in
addition to Controllers, Models, Views
and Helpers there are two more
directories namely, Processors and
Metals. I don't understand what their
significance is.
processors/ is used by ActiveMessaging - it contains ActiveMessaging processors - basically code that gets called as part of communication with a message queue that ActiveMessaging is hooked up to.
metal/ contains code that can best be characterized as 'middleware' - basically, to deploy a Rails application you use a library called Rack which abstracts away the interface between the server and the app itself. It allows you to use the same web server and other infrastructure and switch between different Ruby frameworks - so, if you are using Rails or Sinatra or Merb, Rack lets them all communicate with the same server.
Now, Rack allows you to write 'Metal' code, which is code that gets run directly on the server without the framework getting in the way. The reason you write Metal code is for performance - when Metal code is running, it is running directly rather than with the weight of the Rails framework getting in the way. This way, you can get better performance. I haven't ever had to write any Metal code, so I can't really explain it beyond that.
Extensive usage of .yml files. What
are those for? In rails 2.0.2, all I
came across was the database.yml. Now,
in gitorious, I see gitorious.yml. How
are all these so customized? I mean,
how do rails app(controllers, models,
etc..) communicate with gitorious.yml?
.yml files are files in the YAML format. In Rails, these are mostly used for configuration. Just as XML files are used by Java applications for configuration, .rc files are used in Unix for configuration and .ini files are (were?) used for various apps on Windows for configuration, you can store data in the YAML file which the Rails app uses for configuration. Because of the simplicity of the format, a lot of Ruby and Rails apps use YAML for configuration files.
Ruby has a built-in YAML module that loads these in using methods in the YAML module including YAML.load, YAML.load_file, YAML.load_documents etc. To see how they are being loaded in, I suggest the easiest thing is to find the string "YAML." in the project - or, indeed, the name of the yml files.
With respect to all these questions,
how do I move a level or two up, to
call myself an "intermediate Rails
programmer" from "Rails novice
programmer"? and how do I stay updated
of new api, deprecations, in all
upcoming Rails transitions?
I would suggest that a fair amount of conservatism is appropriate with Rails updates. I'm still using Rails 2.3.3 on a production site, and that's fine. I should probably upgrade to 2.3.8, but I tend to not run with the bleeding edge on production projects.
As for the best way to learn, I'd suggest that you work through Railscasts - these are excellent short screencasts that describe all sorts of useful techniques and help you learn lots about the Rails framework. When you need to do something, obviously there is the API docs - which are okay. The Rails Guides are pretty good and worth reading.
As for books, there's Agile Web Development with Rails - which is a pretty good tutorial. There's also The Rails Way, which is a massive desk reference and in my experience one of the only good ways to learn about some of the minutiae. You might also want to check the StackOverflow question What’s the best resource for learning Rails for a raw beginner? - because although you obviously aren't a raw beginner, the resources recommended are up-to-date and useful for going from novice to intermediate and on upwards. Good luck!