There Is a Way to Handle 'After_Save' and 'After_Destroy' "Equally"

There is a way to handle `after_save` and `after_destroy` equally?

Instead of a block give after_save and after_destroy a method name of your model as a symbol.

class ModelName < AR
  after_save :same_callback_method
  after_destroy :same_callback_method

  def same_callback_method
    # do the same for both callbacks
  end
end

Callback after_[anything]

Here is a one line approach

class Follow < ActiveRecord::Base
  after_commit :reset_cache, on: [:update, :destroy]

  def reset_cache
  end 
end

See: http://guides.rubyonrails.org/active_record_callbacks.html

How to touch a parent model of a `belongs_to` association only if certain conditions are met?

You can try lambda as you said but I'm not sure if its going to work. Something like this:

belongs_to :article, :touch => Proc.new{|o| o.article && o.article.public }

According to the implementation maybe you can try to return nil instead of false in the proc, when it's not available

belongs_to :article, :touch => Proc.new{|o| o.article && o.article.public ? true : nil }

If this doesn't works use a before save callback like this:

class Model < ActiveRecord::Base
  belongs_to :article

  before_save :touch_public_parent

  def touch_public_parent
    article.touch if article && article.public?
  end
end

Let me know if you have any questions.

Update #1

The relevant part from add_touch_callbacks:

if touch_attribute == true
  association.touch unless association.nil?
else
  association.touch(touch_attribute) unless association.nil?
end

So if you pass true, then does a simple touch on updated_at attribute. If you pass a field name then updates that field unless you pass nil. If you pass nil doesn't updates nothing. That's why I said that maybe you can try the second version of belongs_to association.

Is it possible to handle text translations for data stored in database tables?

For user generated content it's best to store the language with the content.

You can then have your users create "copies" of this data with a different language reference.

Depending on how much data you need to change per table a different gems might be suitable for your needs. I18n gem is NOT a good choice here, as it's meant for static content. See: https://www.ruby-toolbox.com/categories/i18n

Show a Notification in Rails after updating a Model

It's not the responsibility of the model to comunicate back to the view. In my opinion this should be handled in the controller, not the model. The controller could look like:

respond_to :json
def create
  if @page.save
    respond_with {:message => "Aye Okay!"}
  else
    respond_with {:message => "Oops, something went wrong."}
  end
end

The destroy and before create cases could follow the same idea: check manually in the controller and send the message from there.

Not exactly what you asked but I think you should keep them separated.

Undefined method for variable_cont in spree - Ruby on Rails

Issue has been solved!

Defined the ransackable_attributes method in associated model Review.rb for custom searchable attributes of that model.

def self.ransackable_attributes(auth_object = nil)
    ['title','review','user']
end

Is it a bad idea to reload routes dynamically in Rails?

Quick Solution

Have a catch-all route at the bottom of routes.rb. Implement any alias lookup logic you want in the action that route routes you to.

In my implementation, I have a table which maps defined URLs to a controller, action, and parameter hash. I just pluck them out of the database, then call the appropriate action and then try to render the default template for the action. If the action already rendered something, that throws a DoubleRenderError, which I catch and ignore.

You can extend this technique to be as complicated as you want, although as it gets more complicated it makes more sense to implement it by tweaking either your routes or the Rails default routing logic rather than by essentially reimplementing all the routing logic yourself.

If you don't find an alias, you can throw the 404 or 500 error as you deem appropriate.

Stuff to keep in mind:

Caching: Not knowing your URLs a priori can make page caching an absolute bear. Remember, it caches based on the URI supplied, NOT on the url_for (:action_you_actually_executed). This means that if you alias

/foo_action/bar_method

to

/some-wonderful-alias

you'll get some-wonderful-alias.html living in your cache directory. And when you try to sweep foo's bar, you won't sweep that file unless you specify it explicitly.

Fault Tolerance: Check to make sure someone doesn't accidentally alias over an existing route. You can do this trivially by forcing all aliases into a "directory" which is known to not otherwise be routable (in which case, the alias being textually unique is enough to make sure they never collide), but that isn't a maximally desirable solution for a few of the applications I can think of of this.

---

Related Topics