I'm trying to come up with an easy solution for creating multipart emails with ActionMailer to make life easier when writing HTML emails and also to make it easy to have a plain-text alternative. Basically, what I would like to have in an ideal world is a simple Markdown with Ruby file to render to a string and use as-is for the plain text mailer and run it through rdiscount or similar for the HTML part.
If you want to use José's approach he's released it as a separate gem. I just tried it with Rails 3.2.6 and it worked first time.
http://blog.plataformatec.com.br/2011/06/multipart-templates-with-markerb/
This is covered quite precisely in Crafting Rails Applications by José Valim. See section 4.2. If I might say, a great idea to use a more agnostic format than HTML for this specific purpose, especially due to the limited nature of HTML email.
My only issue with this section is that it uses a format of .merb to render markdown with embedded ruby, rather than .md.erb.
Related
I am new to rails and trying to understand this concept, as there are many things which we write using helpers(erb/rails tags) can also be written using simple plain html , is there any other advantage to using rails/erb helper than enabling to write more simple and readable code.
As the end result of writing the erb/rails template is always going to be a plain html , so initially by writing plain html do we reduce load on server or reduce servers efforts of converting the rails/erb templates into plain html.
Note: I am specifically asking for more of static templates e.g web forms , links , form contents,etc.
Here're some of merits.
Ability to Collaborate with models and helpers
It automatically generates post url and form labels etc. So, say you're changing the name of a model or url, if you were writing plain html for all templates, you'll have to manually replace all of occurrences on your own, whereas the "rails-way" can handle them all just with one line of modification or one command execution.
Can take advantage of template libraries.
There're lots of awesome template libraries that generate html from ruby code.
https://github.com/plataformatec/simple_form
https://github.com/justinfrench/formtastic
Gives you better abstraction
It gives you good abstraction in the way that it makes you write what you want instead of how you do. For example in my previous project, I was using bootstrap2 and decided to move to bootstrap3. If I were writing plain html, I had to see all html files, and inspect sometimes intricately structured html tags, classes, and find all bootstrap2 specific elements and change them all. But thanks to the template generation gem I was using, all I had to do was basically to upgrade the gem and add a few lines to some config files.
This might seem like a strange question. But have been pondering over this for quite some time now.
Is it better to use RAW HTML in Rails views or to go with Rails view helpers??
If i understand correctly Rails views helpers are converted back to raw HTML. So would it affect the performance of the application by a great deal ??
And is there a tool that would allow me to convert HTML to ERB :)
I'm aware of the HTML to HAML converter.
Thank you,
Certainly better to use a rails helper, as this allows you to create dynamic elements
Use Rails helpers, they guarantee the latest HTML good practice are used and up to date.
i would like to create an application that needs to have the option to print things. I would like to ask if there is a standard way of handling such situations in Rails, or it's just a specific layout to be served when printing is asked. Is there a gem, or a good approach on doing such a thing ?
I'ved used the WickedPDF gem in the past with much success. It's based on wkhtmltopdf and what I really like about it is the PDF is generated based on a view template that's standard ERB (possibly HAML) and CSS.
It's better than going with prawn in my opinion as the template markup/styling can be reused for the PDF itself.
Is there some gem or technique that will let us write only .html.erb templates for our Rails 3 mailers, and gracefully degrade them by stripping HTML tags for the text/plain version, rather than having to create each partial twice?
Google is seriously failing me, so I must be searching for the wrong terms.
take a look at premailer. It can generate text from html.
In general, this is not an easy problem. It might be easier if we were able to write semantic html markup and then it'd be easier to detect intent and convert the html into reasonable looking plain text.
But assuming your html emails are intended for a wide audience, it's full of all sorts of hacks that make the layout work in multiple email clients. This sort of dirty markup will make it harder to generate good looking plain text.
Another issue are things that won't clearly translate into text. Links that say "click here", will look funny in text, for example.
Well, if your html e-mail is simple and can be expressed as Markdown syntax you can use Markerb. It allows you to render multipart e-mails from a single template.
While I have experience developing Rails apps in English, I am a blank slate when it comes to handling globalization, so please don't shoot me in the head if my question 'doesn't make sense' :)
I have been asked to add multi language feature to a part of a Rails app that I am working on. Initially its only going to be 2 languages, French and German. The content that will be translated (which is in English now) is rendered using partials at the moment hence I am getting a bit inclined on creating partials with different languages and then based on the users language selection call the relevant partial - Would you recommend this approach?
Although it seems a heavy weight solution for this particular purpose, but I am also looking at the Rails Globalize plugin. This seems to appeal if I look at the long term gains, something like what if later I am asked to translate the entire app.
Any insights on what would be a proper structured approach to handle globalization in Rails?
Many Thanks
Have you had a look at the i18n (internationalization) API that is in Rails itself as of 2.2? It makes it easy to store your language translation files as .yml files, so a fr.yml and a de.yml or whatever. It also steps through different approaches of making languages accessible via browser prefs, or URLs, subdomains, etc. In your HTML template files you use symbols to specify the keys for the string you've translated. At least in my basic usage and testing, it was very easy to work with.
I preffer using translator instead of Rail's i18n, since the former handles "scoping of translation" automatically. I recommend you give it a look.
This is a great article on how to use Ruby's GetText to localise you Rails App.