#208 ERB Blocks in Rails 3

How does this work with HAML??

You are the reason why I get out of bed on Monday mornings :-)
Thanks for another fantastic episode.

It's worth noting that Rails 3 beta2 has a problem with latest Ruby 1.8.7 and with Ruby 1.9.1. The release notes for Rails 3 beta2 says:

"Note that Ruby 1.8.7 p248 and p249 has marshaling bugs that crash both Rails 2.3.x and Rails 3.0.0. Ruby 1.9.1 outright segfaults on Rails 3.0.0, so if you want to use Rails 3 with 1.9.x, jump on 1.9.2 trunk for smooth sailing."

This change would be ridiculous - is it an April Fool thing? What about legacy code?

I've always followed your brilliant exemplars of the practical effects of release changes, but this time I find it hard to believe it; I will go and check on the release notes - which I've never felt necessary to do before.

PS: I notice you didn't talk about backwards compatibility.

@Andy, great question. I don't use HAML regularly so I haven't researched it yet. I'm guessing the HAML library will need to be updated to handle this as well.

@Slobodan, Thanks for pointing this out. I hope beta3 will soon be released with these version fixes.

@Steve, what specifically do you not like about this update?

Regarding backward compatibility. Leaving out the equal sign still works in Rails 3 but it is deprecated. So if you are building an engine that has views which need to be compatible with both Rails 2 and Rails 3 then it's best to not use the equal sign for now.

I'm not certain in what other scenarios you'll need backwards compatibility.

@Ryan, I think that this is a "big" update - unless I have been putting too much of my effort into views.

It is a fact that every developer has had to understand the difference between Ruby code which returned content, and Ruby code which affected the logical flow of content within the view.

This change seems to alter the syntax for the sake of some new paradigm, whilst still retaining the anomaly of the "cache" facility.

I cannot see why the backward compatibility cannot be guaranteed for the foreseeable future.

As to your point about other scenarios, I can't think of any, but unless you're using extensive JQuery (or javascript), I believe that views are a fundamental resource of any Rails application.

I shall still watch your impeccable Railscasts despite my pique on this issue with Rails 3!

Further to my comments, as someone who has seen (and worked in) the dramatic expansion of IT from the 70s (IBM), through the 80s and 90s (Microsoft), and the 21st century (Microsoft/Apple/Open Source), I am concerned that new releases of established frameworks/products will require upgrading in a way which requires expensive in-house/consultany effort which would not be otherwise necessary.

Cannot some bright chap in the Rails community (I'm too thick) produce a plugin which emulates backward compatibility in this area; or at least a migration tool which identifies and converts heretic syntax to its new spiritual home?

@Steve Yes, that would be ideal. Unfortunately, the Rails team and open source does not have the funding of MS or Sun/Oracle. While I agree the Rails team should make each version backwards compatible, I think framework innovation would be slowed. Rails 3 is a major version so expect it to have breaking changes.

@anon Yes I understand the constraints; but the drivers of Rails 3 have put an extraordinary amount of effort into the new framework. I'm just a bit disappointed, that having created a game-changing technology, they have not put (in my opinion) enough thought into the time and resources their "adherents" have expended in developing businesses/sites which follow their lead.

To an old man, this seems IBM/Microsoft ish rather than community-sensitive progress.

I shall now be silent, as I'm sure I'm offending the majority.

This cast came just in time. I was getting duplicate output due to yields that I had in the helpers. The cast pointed me in the right direction and was able to solve the problem quickly. Thanks.

This fundamental change in the handling of ERB makes for better streamlined helper code. It's a good design improvement. Although it potentially breaks legacy code, it's well worth it.

@Andy: you can easily do this with haml.

="string" == <%= "string" %>
-"string" == <& "string" %>

@Steve D: Why is full backwards compatibility important in a major release? Rails 2.x isn't going anywhere, it's feature packed, and if necessary will receive security updates for the foreseeable future — Rails 3 won't make 2.x any less awesome! I can see many production Rails 2.x apps never needing to be upgraded.

What makes Rails great is it *isn't* an enterprise framework, it's driven on innovation by developers who like to move fast. Let's not bog that down with specs and red tape.

Drupal does no gurantee backward compatibility. If you want to lead by innovating, sometimes you have to sacrifice legacy. We always do that.

I think it is a positive step by Rails community to carry a vision to have backward compatibility where possible only if it does not slow down innovation.

Despite my vow of silence, I just want to reply to a couple of (good) points.

@Ashley I agree that full backward compatibility may be inappropriate for a major release, but I should have thought that such a major element of MVC should at least have an easy migration path, or a long-lasting "compatibility mode". It seems to me that either would be relatively easy; and ideally, should be integrated into the official Rails releases, rather than waiting/hoping for one (or more) individuals in the community to chuck in such tools or plugins.
I also take your point on the ability to stick with 2.x, but I don't really believe that fixes and minor releases are going to be abundant in the coming years.
I also get your comment that this "product" is driven by developers who want to move quickly (of whom I am an avid member); but development is - like it or not - but a minor part of the lifecycle, and we must always have an eye to the legacy we are leaving.

a railscast about authentication in rails 3 would be really nice.

What happened to #capture helper method ? What is the difference of it and new #with_output_buffer ?

Well, I don't know where you find the time to get to grips with all the new functionality that's going on and I really ought to say thank you as your Railscasts have saved my bacon many times.

I am a little dissapointed and rather pleased at the same time with this new form functionality.

I've been looking forward to Rails introducing form inheritance and I had an incling that Rails 3 mught just be the time this ws done but alas it seems to be not the case. I believe this is a major oversight in Rails particularly when everything else is an object. The pleasing thing is to see the view helpers becoming more friendly and intuitive to use but they are still not a substitute for form inheritance.

Thankyou for your massive contributions to the Rails community

James

Thanks Ryan. When this change showed up in Rails master just a little bit before beta 2 I was sort of wondering what the proper form (no pun intended) would be, now, for those of us writing helper methods.

This confirms the direction I was going with my collection_check_boxes FormBuilder mixin, since I'm not outputting any extra content, just yielding a specific object to the block, more like fields_for than form_for.

I get this error using rvm:

mark@macpro:~# rvm install ruby-head
Installing Ruby from source to: /Users/mark/.rvm/rubies/ruby-head
Running autoconf
Configuring ruby-head, this may take a while depending on your cpu(s)...
Compiling ruby-head, this may take a while, depending on your cpu(s)...
Installing ruby-head
Installation of ruby-head is complete.
Updating rubygems for /Users/mark/.rvm/gems/ruby-head@global
Updating rubygems for /Users/mark/.rvm/gems/ruby-head
Installing gems for ruby-head.
Installing rdoc
Installing
Error running '/Users/mark/.rvm/rubies/ruby-head/bin/gem install --no-rdoc --no-ri ', please check /Users/mark/.rvm/log/ruby-head/gems.install*.log
Installing rake
Installing
Error running '/Users/mark/.rvm/rubies/ruby-head/bin/gem install --no-rdoc --no-ri ', please check /Users/mark/.rvm/log/ruby-head/gems.install*.log
Installation of gems for ruby-head is complete.

I'm loving the Rails 3 with all it's new features, but I'm having problem with the ruby process literally EATING memory. With each request the process grows with perhaps 10 mb. Does anyone know why this is? Working on a Mac and a SQLite DB.

Thanks a lot Ryan for all your hard work! This web site is really inspiring for many people and slowly but surely becomes "Ruby on Rails encyclopedia"!

i'm late on this is great episode..

When I try to install ruby-head using RVM i get the following error message:

run with --debug for full backtrace
make: *** [rdoc] Error 1
[2010-04-10 14:22:10] make
uh-oh! RDoc had a problem:

Directory .ext/rdoc already exists, but it looks like it
isn't an RDoc directory. Because RDoc doesn't want to risk
destroying any of your existing files, you'll need to
specify a different output directory name (using the
--op <dir> option).

Any idea what can be going wrong? And how do I specify rvm to install without RDOC?

Thanks.

Does anyone have a solution to the ".ext/rdoc already exists" problem?

@Roel

You didn't include the important line which should be just above where you started cutting. If you saw the same message I had it said it could not find yaml.h, "please install libyaml". So go ahead and install libyaml :-) (and libyaml-devel, if that's a different package)

@Luis: yes "rm -r .ext/rdoc" followed by "make install".

Another great one. Thanks for all you do!

Cool episode! This would get me confused for a while :P

About backwards compatibility, I see it as good for 2 things: Stimulation to produce outdated code, and some more IFs in the code, adding up to a slow platform.
I simply trust Rails team, great work guys. And since it is O.S. just add your local path :)

I can't agree with Fabiano that backward compatibility stimulates the production of outdated code; but I must say I'm impressed if he is able to remove those performance-degrading conditional statements from his Rails code.

Sorry, I probably expressed myself in the wrong manner, english is not my mother language.

Correcting, my point was that: in order to keep backwards compatibility, the framework/language/core must keep it open to the old format, and when you think just about 1 or 2 functions it doesn't really matter, but if becomes a policy and everything is backwards compatible, when you take the time to analise, every page request takes hundreds of IFs more than the non-compatible way.

I'm not saying that backwards c. is all bad, not whole! But if your app uses too much an old function and you decide *must* upgrade, just add your own path to that function

@Fabiano
Ok, I understand your point and I apologise for my assumptions of what you meant.

However, I still feel that backward compatibility woul be appropriate for at least 18 months after the final Rails 3.0.

I should add that I am only looking at the View component in terms of backward compatibility; I don't see that the other improvements/revisions will have a substantive impact.

Guys, can we please stop talking about Rails 3? It's still in BETA.
Let's just concentrate on rails 2.3.x? It's what we are all using and Ryan, I am sure everyone here will appreaciate your coverage on rails 2.3.x.

thanks

Hi Ryan,

great video, as usual.

I have a question, not directly related to ERB, but more to blocks. Why use the '&' sign when passing a block as an argument?

When running the rails update checker, I found i did have to provide an = for the each method, such as <%= @comments.each do |comment| %>

To those who want to see rails 2.3.x, rails 3 will most likely go into full release later this year. Personally, id rather start seeing this stuff now, to keep up with the curve.

On another note, anyone else in converting an app rails 3 have trouble using resources stored in the public folder such as stylesheets?

Ryan, is this what you mean by using the "capture" method?

Rail2 and Rails3 beta3 process <%= '<h1>hello</h1>' %> differently.

Rails3 must use <%= capture {'<h1>hello</h1>'} %> to get the same
result as Rails2

Is this intentional or is it a bug?

I am apreciating it very much.I have never read such a lovely article and I am coming back. Site dizin olarak elimizden geleni yapalım

what does the --pre option do in gem install?