Project

nofly

0.0
No commit activity in last 3 years
No release in over 3 years
When we send communications to users it is usually in response to an event. Users often have their own communications preferences (when/how/what). This logic can easily become complicated and so I developed Nofly to abstract it and let the core application only worry about knowing what event happened to which object/record.
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
 Dependencies

Development

>= 0
>= 0
 Project Readme

Nofly¶ ↑

What is it?¶ ↑

Nofly takes your logic for emails and other notifications out of the controller and put it into its own context

Why would you do that?¶ ↑

When we send communications to users it is usually in response to an event. Users often have their own communications preferences (when/how/what).

This logic can easily become complicated and so I developed Nofly to abstract it and let the core application only worry about knowing what event happened to which object/record.

Example¶ ↑

class FooController < ApplicationController

  def bar
    @foo = Foo.create foo_params 
    Nofly.for(@foo).bar
  end

end

class FooNofly < Nofly::EventLibrary
  // check user preferences 
  // send emails, 
  // send push notifications
  // etc.
end

Installation¶ ↑

Add an autoload path for the directory you’ll keep your nofly config.autoload_paths += Dir[“#{config.root}/app/nofly”] to application.rb

Explain the name¶ ↑

Notifications shouldn’t be done on the fly, and Ruby gems already has a ‘Notifly’