I have a number of mailers in my Rails 3.2 application, and I would like all of them to use the same email layout. That layout includes a header and footer, which includes images to be used inline. I'd like to follow the DRY principle of Rails, but I'm not entirely sure what the best practices are for this.
As this answer points out, I can use AbstractController::Callbacks to create a before_filter to add inline attachments. But how do I do this as well as set the layout in one module that I can then include in the mailers?
Ideas I have at the moment are to create a new mailer class called DefaultMailer, then have all mailers that I want to use the layout inherit from that class. Or to create a concern that would handle these tasks. Before attempting to hack something together using one of those techniques, I thought I would ask here to see if anyone had done this successfully before to help guide me.
AFAIK there are some issues when inheriting from other mailers (ie. not inheriting the settings).
Common solution is to create a mailer base module. This is a snippet from existing project:
module MailerBase
extend ActiveSupport::Concern
included do
helper :application
layout 'mailer'
default from: "#{AppConfig.application_name} <#{AppConfig.mailer_sender}>"
end
end
You can combine this with your callbacks, although including remote images is more common and arguably better solution.
Related
I'm refactoring a legacy code and one of the things it must be done is moving related controllers into a new folders. The thing is that it is a huge project and if I move the controllers I will need to redefine the paths on controllers and views which is quite impossible, also with the addition that maybe I will forgot something that it is no properly tested.
Is there any way to move controllers into folders without affecting the routes? Or is there any way to redefine easily the path of the resources? OR is there any easy way to say that a namespace don't has to add a prefix like 'api/controller#action? (don't add 'api/')
Thanks in advance.
For those how migth need an answer to this question it is on http://guides.rubyonrails.org/routing.html Just check 2.6 Controller Namespaces and Routing and you will find this:
The default ruby on rails scaffolds generate a new.haml or new.erb these include only 1 line: = render 'form'
Thus, basically the file is obsolete, is there any preferred way to remove the new partial and make it use the _form partial instead straight away or would this go against rails conventions?
no, there is no preferred way. it goes against rails conventions.
TL;DR don't do it.
if you don't need any customizations on your templates and are just creating basic CRUD stuff, have a look at admin tools like RailsAdmin ActiveAdmin Typus etc.
I would like to write a helper that will only be used in my spec files and I do not know where this code should go.
I am not trying to test an app helper and I do not feel like creating an app helper that will only be used for testing.
What is the good practice?
Thanks,
Typically I put these in spec/support/spec_helpers. I then include those modules in the appropriate examples.
If you have some that are useful to all specs of a certain type (e.g. all request specs) then you can do
config.include SomeHelper, :type => :request
which will include that module into all your request example groups.
In a Rails 3.1 app, one controller needs to have all its views compile whatever Sass stylesheets they might need per request using a set of custom variables. Ideally, the compilation must happen via the asset pipeline so that content-based asset names (ones that include an MD5 hash of the content) are generated. It is important for the solution to use pure Sass capabilities as opposed to resorting to, for example, ERB processing of Sass stylesheets.
From the research I've done here and elsewhere, the following seems like a possible approach:
Set up variable access
Create some type of variable accessor bridge using custom Sass functions, e.g., as described by Konstantin Haase here (gist). This seems pretty easy to do.
Configure all variable access via a Sass partial, e.g., in _base.sass which is the Compass way. The partial can use the custom functions defined above. Also easy.
Capture all asset references
Decorate the asset_path method of the view object. I have this working well.
Resolve references using a custom subclass of Sprockets::Environment. This is also working well.
Force asset recompilation, regardless of file modification times
I have not found a good solution for this yet.
I've seen examples of kicking off Sass processing manually by instantiating a new Sass::Engine and passing custom data that will be available in Sass::Script::Functions::EvaluationContext. The problem with this approach is that I'd have to manage file naming and paths myself and I'd always run the risk of possible deviation from what Sprockets does.
I wasn't able to find any examples of forcing Sprockets processing on a per-request basis, regardless of file mod times, that also allows for custom variable passing.
I'd appreciate comments on the general approach as well as any specific pointers/suggestions on how to best handle (3).
Sim.
It is possible. Look here SASS: Set variable at compile time
I wrote a solution to address it, I'll post soon and push it here, in case you or someone else still need it.
SASS is designed to be pre-compiled to CSS. Having Sprockets do this for every request for a view on a per request basis is not going to perform very well. Every request is going to have to wait for the compilation to be done, and it is not fast (from a serving-pages point of view).
The MD5 generation is within Sprockets, so if you are changing custom variables you are going to have to force a compilation on every single request to make sure that changes are seen because the view is (probably) not going to know.
It sounds as though this is not really in the sweet-spot of the asset-pipeline, and you should look at doing something more optimised for truly dynamic CSS.
Sorry. :-)
I want to be able to override models and controllers of my rails 3 engine in the base app.
Inspecting $LOAD_PATH, I found engine's 'app/{models,controllers}' there, but I can't explicitly require engine's model or controller file: require 'engine_name/model_name' fails with "no such file" (tried with both namespaced(app/controllers/enginename/*) and plain engine).
So, what's the best way to extend engine's models/controllers in rails 3 without copying them to base app?
Basically, it's a load order problem. So, if I explicitly require model from engine, everything's ok, but I hope there is a better way.
So I actually went back and wrote the documentation. The answer is to Open Class the Controller and Model classes using either,
Class#eval_class
ActiveSupport::Concern
More details here,
http://guides.rubyonrails.org/engines.html#overriding-models-and-controllers
(edited. Changed from "edgeguides" subdomain to "guides" subdomain)