Writing Rails Templates in Pure Ruby - ruby-on-rails

I have a large number of views in my Rails application that both:
Have a consistent and repeated structure, and
Involve the use of helpers that accept large hash inputs.
As such, I would like to write these views directly in Ruby (using a DSL/helpers that I would write).
How can I get Rails to allow me to write .html.rb views?
Thanks!

Add an initializer with:
ActionView::Template.register_template_handler(:rb, :source.to_proc)
Then you can write .html.rb views in ruby, they should return a String of the desired context when executed.

Related

Rails: best practice to load a helper in controller

I was hired some days ago to update a Rails 4 app. In general the rspecs and the code look good however in the top of some controller a found this line:
delegate :edit_app_path, :new_app_payment_path, to: :view_context
Searching in the net, I found that the line is a way to load methods from the helpers inside a controller through a new instance of ActionView::Base class. I mean, is a way to do it instead of the classic:
include MyHelper
in the controller. My question is: is this really a good practice? is faster? AFAIK, view_context will load a new class with all the helpers and all the context of the view instead of one helper if I use the classic "include MyHelper". By the way :edit_app_path and :new_app_payment_path methods are in the same helper.
Should I remove the line?
Using view_context allows the controller to be blissfully ignorant of where the path is defined. If the helper file structure is refactored in future, the controller will continue humming along without requiring change.
Performance wise, I doubt the impact will be significant since all the code will have been loaded. Rails (and the Ruby standard library) creates new objects all the time.

How does Rails View Helper work

I recently came across a tricky situation related to rails view helpers.
The situation is like follows-
I am having a controller as Feature1::Feature1.1::Feature1.1.1Controller.
The Feature1.1 also includes other controllers like Feature1.1.2Controller, Feature1.1.3Controller...
So ofcourse related view helpers in folder app/helpers/feature1/feature1.1/...
Now the real problem I am facing is that a few helpers for feature1.1 includes the same method name method1 with related definition.
I was wondering how rails identifies all these helpers as I am noticing that the method1 i.e. being called in a view for the controller feature1.1.1 is using the definition of the method1 i.e. written for the controller feature1.1.2.
So does rails consider all helper modules defined in one folder as one?
In a view feature1/feature1.1/feature1.1.1/index I am making a method call for method1.
I am using rails3
It depends a little bit on your Rails version. With eralier Rails versions, Rails did only include application_helper.rb and <controler_name>_helper.rb.
Additional helper modules can be included via helper :helper_name1, :helper_name2, ... within your controller.
With later Rails verions (4.2.? and up, maybe previous versions too), Rails includes all helpers within your helper folder at once. You can set config.action_controller.include_all_helpers = false within application.rb and you will fall back to the old behaviour.
This makes the helper only available within your views. If you want to use a helper within your controller you still have to include your helper with include XXXHelper.
I did some research and would like to share some additional info.
As per #slowjack2k mentioned, view helpers are included by rails as a default behavior.
But my question was about the situation of same method names across multiple helpers.
I found this article to be useful in this scenario. Though it explains the behavior for Rails 4 but I found it behaves in the same fashion for Rails 3.2.2.
I will summarize the article -
If there will be any conflict in the same names of methods in different helper modules, rails will use method from latter file (alphabetically)

HTML Purifier equivalent for Ruby on Rails?

Has anyone encountered an equivalent to HTMLPurifier for Rails apps? Essentially I need to clean up often terribly formed HTML generated by users before saving to the DB.
http://htmlpurifier.org/
You can use the sanitize method.
sanitize(html)
There is also a Sanitize gem.
Sanitize.clean(html)
I tend to prefer the Sanitize gem because it can be used as a before_save filter in your models instead of having to use the sanitize method in each of your views.

Internationalizing whole text with markup in Rails 3

What's the best practice for internationalizing, say, a Terms of Service document in Rails 3? I can think of two options:
Creating a partial for each locale and choosing which one to load according to the current user's locale.
<li><%= I18n.t :tos_paragraph_1 %></li><li><%= I18n.t :tos_paragraph_2 %></li>
None of these seems like a good solution. Any ideas?
There are a few solutions, but if I were doing this for a production project, I would probably do something like the following:
Create files for your translated Terms of Services in config/locales/terms/, naming them terms.en.html, replacing en with the locale for each translation and html with the format of the file (e.g. you could use Haml, Markdown, etc.).
Create the following helper methods (put them in app/helpers/application_helper.rb to use them everywhere, but you can put them in whatever helper file you need/want):
def localized_document_for(document, locale)
raise ArgumentError.new('nil is not a valid document') if document.nil?
raise I18n::InvalidLocale.new('nil is not a valid locale') if locale.nil?
localized_document = path_for_localized_document(document, locale)
raise MissingTranslationData unless File.exists?(localized_document)
# If you're using Markdown, etc. replace with code to parse/format your document
File.open(localized_document).readlines.join
end
def path_for_localized_document(document, locale)
"#{Rails.root}/config/locales/#{document}/#{document}.#{locale.to_s}.html"
end
Now, in your views, you can use localized_document_for('terms', I18n.locale) any time you need to get the contents of the Terms of Service in the user's language. Now the code you're using to fetch the document is DRY (you can easily fetch other documents by creating another directory in config/locales and changing the value of the document argument), and your translated documents are stored in their own directory and can easily be edited (and don't depend on YAML, which brings no value to storing a single document in a file).
Note that if you wanted to do it the "Rails 3 Way," you could use the I18n::Backend::Chain (see https://github.com/svenfuchs/i18n/blob/master/lib/i18n/backend/chain.rb), and pass in I18n::Backend::Simple.new along with a custom backend that reads the files as necessary, but for a one-off deal I believe the helpers work sufficiently.
Creating a partial for each language is definitly undry.
The Rails way is the second option you suggest with a .yml for each language.
The doc provides great examples to let you organize the yml according to each page. Thus you have shortcuts for all your variables.
See http://guides.rubyonrails.org/i18n.html

XML => HTML with Hpricot and Rails

I have never worked with web services and rails, and obviously this is something I need to learn.
I have chosen to use hpricot because it looks great.
Anyway, _why's been nice enough to provide the following example on the hpricot website:
#!ruby
require 'hpricot'
require 'open-uri'
# load the RedHanded home page
doc = Hpricot(open("http://redhanded.hobix.com/index.html"))
# change the CSS class on links
(doc/"span.entryPermalink").set("class", "newLinks")
# remove the sidebar
(doc/"#sidebar").remove
# print the altered HTML
puts doc
Which looks simple, elegant, and easy peasey.
Works great in Ruby, but my question is: How do I break this up in rails?
I experimented with adding this all to a single controller, but couldn't think of the best way to call it in a view.
So if you were parsing an XML file from a web API and printing it in nice clean HTML with Hpricot, how would you break up the activity over the models, views, and controllers, and what would you put where?
Model, model, model, model, model. Skinny controllers, simple views.
The RedHandedHomePage model does the parsing on initialization, then call 'def render' in the controller, set output to an instance variable, and print that in a view.
I'd probably go for a REST approach and have resources that represent the different entities within the XML file being consumed. Do you have a specific example of the XML that you can give?

Resources