I'm not sure I understand the difference between html.erb or haml.erb files and .erb files in the views for a Ruby on Rails application.
What are the dis/advantages of each (html.erb/haml.erb or .erb/.haml) files?
PS I'm not asking about the difference between the erb and haml files -- just appending the extension to an html file versus not appending it.
Mainly this is about content-type and if you have any respond_to blocks in your controller. If you declare your file with a .html.erb or .haml.erb extension you are reducing the scope of response that those files can be used, which will only be served if the request is for the mime type. When using only .erbyou expand the usability of your file, not restricting it's response type.
Related
Why naming convention of views files in rails are considered as action.html.erb only ( instead of action.erb.html ) ?
What will happen if we write views files as action.erb.html ?
What will happen if we write views files as action.erb.html?
The first thing that will happen is that the Ruby syntax highlighting in your editor will stop working as the file extension is now .html instead of .erb. On almost every file system in use the file extension is the rightmost part of the file name.
The second thing that will happen is that Rails will no longer be able to lookup the template and even if it could it would no longer process it through ERB as it no longer has the .erb file extension.
.html is just a segment of the file name that lets the rails template resolver distinguish between templates for different formats when looking up a template for a given request format. Its not really technically part of the extension. For example:
show.html # just HTML - no processing
show.html.erb # a HTML ERB template
show.html.slim # a HTML Slim template
show.html.haml # a HTML Haml template
show.xml.erb # a XML ERB template
show.xml.slim # a XML Slim template
show.xml.haml # a XML Haml template
show.json.erb # a JSON ERB template
show.json.jbuilder # a JSON jBuilder template
TRDL; changing the file extension is a dumb idea. Especially when you consider that Rails actually supports multiple template engines such as jbuilder, Slim and Haml in addition to ERB.
Well since I am using a lot of helper methods in my view files and I avoid using html in most of my view files.
Example
myview.html.erb
<%=myhelper #myobject%>
so I end up using,the erb processing tags each time for each file.
<%=%>
I want to register .rb as a template handler or any other extention for that matter.
So my templates look like
myview.html.rb
myhelper #myobject
I am clueless on how to go ahead.
I found it,it seems railscasts already covered that part.
Its show notes,worth checking out.
https://github.com/railscasts/379-template-handlers/blob/master/store-after/config/initializers/ruby_template_handler.rb
Things without ruby are easy to read and render without those erb tags.
I added a div to my haml file:
%section.splunk
.splunk_results Loading splunk data...
that will later be populated by an ajax call. However, it isn't showing up in my html file, even when I restart rails and navigate to that page. My research showed that it should auto-compile when I load the page -- why isn't this so?
EDIT:
The haml file is located at myAppName/client/order_details.haml. The HTML that it should be presumably compiling to is in myAppName/public/templates/order_details.html.
HAML files get interpreted as HTML files using the asset pipeline, which requires that your file be in app/assets.
Additionally, the controller action specifies the file that will be rendered. Take a look at your Rails logs to see what file the action is actually rendering.
I'm a rails developer trying to learn Backbone and then I ran into this problem: since Underscore templates include symbols like <%=%>, I guess templates can't be included into erb files, so is it okay to have a rails partial for every single template? And what extension should it be?
You can escape the erb symbols by using two % in the opening tag, and put your backbone templates in the rails views:
<script type='text/template' id="my-template'>
<%%= name %>
</script>
will output the following in your page:
<script type='text/template' id="my-template'>
<%= name %>
</script>
Putting your Backbone templates directly in your rails views is IMHO the best option when you're trying to learn. You're already wrestling with the new concepts, no need to add another hurdle.
Starting with Rails 3.1, it provides two things that make working with Backbone templates a little easier: the asset pipeline, and automatic JST (JavaScript Template) compilation.
Create a directory in your app/assets folder called templates. This directory will automatically be picked up by the asset pipeline.
Next, name the files in that directory with an extension of jst and the type of template you are creating ejs (embedded javascript). You can even nest them in directories. For example:
app/assets/templates/my_template.jst.ejs
app/assets/templates/bookmarks/show.jst.ejs
The asset pipeline also allows you to use other templating languages like embedded coffeescript, mustache, handlebars, etc. by simply changing the file extension (and including any necessary gems).
Now to reference your JST templates in your Backbone views, simply use the path to the filename:
var Bookmark = Backbone.View.extend({
template: JST['bookmarks/show'],
render: function() {
this.$el.html(this.template(this.model.attributes));
return this;
}
});
You may need to add this line to your application.js:
// require_tree ../templates
Here's a nice article which explains all of this in a little more detail: http://www.bigjason.com/blog/precompiled-javascript-templates-rails-3-1
Where should you put your Backbone templates? I'd say nowhere. I believe that in most Rails applications, the server should be responsible for all rendering of HTML, while the client-side JavaScript should just be responsible for inserting that rendered HTML into the DOM. Among other things, this makes I18n easier.
The exception would be if Rails is simply being used as a lightweight backend for an application that runs mostly on the client side (though in that case, you might want to use Sinatra or something instead). In this case, Rails should probably render nothing, and have the JS do all the rendering.
Notice the underlying principle here. Either the server should be responsible for all rendering, or the client should. Splitting it will make life harder.
I'm trying to allow the user to customize my application using YML files.
When the user updates certain things the CSS needs to be updated as well.
I'd like to solve this problem using dynamic CSS instead. The way I was planning on doing this is to have a settings SCSS file which the other css files import and use.
Here is what I have so far:
settings.scss.erb:
$width: <%= Rails.application.config.width %>px;
main.css.scss:
//= require settings
#import "settings";
#main {
width: $width;
}
But I get this error:
Invalid CSS after "$width: ": expected expression (e.g. 1px, bold), was "<%= Rails.appli..."`
So It seems that the settings are not being passed through the erb parser before being handed off to the SCSS parser, is there any way to solve this.
I'd rather not put everything in .erb files since my text editor doesn't support (syntax highlighting and commands) when having scss in erb files
Side stepping the problem where ERB is not being parsed, you are not going to be able to customize the CSS dynamically (I think the main file may require an erb extension). The asset pipeline is designed to serve assets in a way that tells browsers that the are static and are not going to change.
Assuming the erb parsing was working, the width would be rendered during the precompile phase, or on the first request. If you are using Sprockets far-future headers are set to tell the remote clients to cache the content for 1 year. And Sprockets only picks up changes if the timestamp of the file changes, so would never get any new values.
You could force Sprockets to dynamically serve every request, and to not send any headers, but it is not really designed for this and there are significant performance risks in doing so.