If you want to maintain separation you could add after_update and
after_destroy callbacks that only send a message using
ActiveSupport:notifications.
You then write a subscriber to that notification which zaps the cache.
Same result, but instead of observing, it listens. It also makes it
explicit in your model code that after update and destroy a message is
sent into the system which may be acted upon.
On 06/12/12 16:47, Svoop wrote:> Observers will be no more as of Rails 4, farewell, never been much of
> a fan. However, I''m using it in one of my gems which enables model
> attributes for use with a WYSIWYM editor. The resulting markup is
> persisted, but in order to use it in a view, it has to be nokogiried
> in a helper which fragment caches the result. This cache has to be
> zapped once the model instance is either updated or destroyed. An
> observer for after_update and after_destroy seemed the obvious choice
> at that time.
>
> What would be a Rails 4 approach for this without observers? Inject
> after_update and after_destroy callbacks directly into the model?
>
> -sven
> --
> You received this message because you are subscribed to the Google
> Groups "Ruby on Rails: Talk" group.
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
>
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit
> https://groups.google.com/d/msg/rubyonrails-talk/-/tpPLDCE1jakJ.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.