When I run:
ERB.new("1. <%= ERB.new('2').result binding %>. 3").result binding
The output is:
2. 3
While the expected output is:
1. 2. 3
Seems like the nested erb is deleting everything before it in the template. Has anyone seen this before? What is the recommended way of nesting erbs? Is it possible?
There is a conflict in the namespace specifically in the _erbout variable which is reinitialized by the nested ERB.
This exact case of nesting ERBs is mentioned in the documentation of ERB.new() saying that the variable has to be renamed using :eoutvar attribute if you are operating in the same scope (binding).
ERB.new("1. <%= ERB.new('2', eoutvar: \"_erbout2\").result binding %>. 3").result binding
#=> "1. 2. 3"
Related
The release notes for Rails 3.0 include this change:
7.4.2 Helpers with Blocks
Helpers like form_for or div_for that insert content from a block use <%= now:
<%= form_for #post do |f| %>
...
<% end %>
Your own helpers of that kind are expected to return a string, rather than appending to the output buffer by hand.
Helpers that do something else, like cache or content_for, are not affected by this change, they need <% as before.
We're in the process of migrating a web application from Rails 2.3.18 to Rails 3.1.12, and it would be very useful to have a complete list of such helpers that have changed, so that we can check all of their occurrences in our source code, but I'm having trouble finding an authoritative list of this kind.
I've tried looking through the git history of the rails project, but there seem to be many commits with related changes, and they're not obviously grouped on particular branch. For example, it seems to be clear that this list includes:
form_for
form_tag
fields_for
field_set_tag
... from 7b622786f,
link_to
... alluded to in e98474096 and:
div_for
content_tag_for
... alluded to in e8d2f48cff
remote_form_for
.... alluded to in 0982db91f, although it's removed in Rails 3.
However, I'm sure that's not complete - can anyone supply a complete list?
i don't have a complete list, but i think that you can derive most of what has changed from having a look at the diff in documentation of UrlHelper and FormHelper. most of the methods in those helpers changed to the new syntax.
http://apidock.com/rails/v2.3.8/ActionView/Helpers/UrlHelper/link_to
http://apidock.com/rails/v2.3.8/ActionView/Helpers/FormHelper/form_for
There is a list of these methods in the rails_upgrade plugin, whose purpose is to check your application for problems on upgrading from Rails 2 to Rails 3. The relevant method is check_old_helpers, which checks for block helpers containing any of:
content_tag
javascript_tag
form_for
form_tag
fields_for
field_set_tag
As for how authoritative this is, this plugin is an official Rails project plugin, although it does miss out a couple that I found by searching the git history:
div_for
remote_form_for
link_to
However, if the official tool for checking for these helpers is missing some, perhaps this is as good a list as I'm likely to find. Another point is that the upgrade check tool mentions that there should be deprecation warnings if you miss some, which provides an additional check:
Block helpers that use concat (e.g., form_for) should use <%= instead of <%. The current form will continue to work for now, but you will get deprecation warnings since
this form will go away in the future.
I'm trying to figure out how you can herald a Ruby block in a <%= ... %> emitter.
No problem with the '<% form_tag do %>' part, but as I dig into Rails internals
and see how it uses erb to process templates, the generated Ruby code is invalid,
due to that hanging 'do'. Is there a post-processor hiding in Rails somewhere that
straightens out the code before running it? If yes, where is it? If no, how does
Rails pull HTML and Ruby code out of this form?
Rails added a hack which uses a regular expression to figure out if what is passed to erb is a block expression and then handle it differently.
For a more detailed explanation: http://timelessrepo.com/block-helpers-in-rails3
I'm working on upgrading an old Rails app (1.1.6) to Rails 3. Obviously, a lot has changed. One thing appears to be that Rails automatically escapes content dropped into the view. However, I have a situation where I have a helper generating IMG tags for me, and Rails is automatically escaping the resulting content.
<%= random_image('public/images/headers') %>
This results in escaped content, much like one would expect had I done this (in 1.1.6)
<%= h random_image('public/images/headers') %>
Is there a way to tell it to not escape?
<%= raw random_image('public/images/headers') %>
.html_safe
It may need to be inside the helper
There are there ways in which this can be achieved in rails 3 application
html_safe
raw
h
raw and h can only be used in controller and views these methods are defined in helpers.
html_safe can be used anywhere in a rails application i.e., can be used in models, helpers, controller etc.
For more information please read http://yehudakatz.com/2010/02/01/safebuffers-and-rails-3-0/
Trying to use my active record translations in config/locales/de.yml also in my views. I thought I am clever using this:
de:
activerecord:
attributes:
user:
login: "Benutzerkennung"
comment: "Bemerkungen"
And in my view this:
<%= label_tag :login, t('activerecord.attributes.user.login') %>
But instead of the translation value ("Benutzerkennung") I am getting the infamous
"translation missing: de, activerecord, attributes, user, login"
Has anybody got this working (not using the label translation plugin (I am wary of potential side effects), or User.humanize_attribute_name)? What am I missing? (it does work when I use "activerecord1" or something else than activerecord, so my setup seems to be fine)
Thanks!
Ok, my bad, it does work just fine. I fell in the YML formatting trap :(
To help you debug along the way, use "script/console" and the following statements:
- I18n.locale --> should output the locale you want to examine
- I18n.t('activerecord.attributes') --> should give you all the key/value pairs for your translation, if not, you made a formatting error in your YML file or it could not be found
And btw - the plugin works quite well http://github.com/iain/i18n_label/
if you don't like the result of ".human_name" (which the plugin uses), just fall back to I18n.t('your key')
Another method:
<%= label_tag :login, User.human_attribute_name(:login) %>
You should upgrade Rails gem to v2.3.11 (I tried to use 2.3.9, but now days it is not available so I suggest you 2.3.11)!
gem install -v=2.3.11 rails
You can find this issues documented here: Rails 2.3.9 Release notes
Hi i converting rails views from erb to Haml .The issue i faced is when use the form_for the haml throws the UNEXPECTED $end error. I am sure i did the space indentation well with in form_for .......Even if i use "each do" loop is says the same error. if i revert the haml to erb it works fine.
Rails version i used : 2.3.2 & i installed haml gem 2.2.19 as well as haml plugin also.
my controller code :
def new
#user = User.new
end
My View code :
.contentContainer.signup
- form_for(#user) do |f|
Make sure your haml indentation is perfect.
.contentContainer.signup
- form_for(#user) do |f|
= f.text_field :name
Are you including - end in your templates? Haml takes care of ends for you, so if you add your own, it won't work.
Can you paste your entire template (in a code block, so it's formatted properly)?
There's also a good command-line tool to make transition easier: html2haml. It doesn't always produce the prettiest haml, but it certainly works.
Hey, there's even a web-based form for this: http://html2haml.heroku.com/
Generally, be sure your indentation is perfect. haml is very particular about indentation. If you use a decent editor (such as textmate or vim) this is an easy task.
If the last line in file is indented there has to be an addidtional, empty line.