這可能是一個好地方,使非ActiveRecord的模式。我明白現在問題已經解決了,這有點超出範圍,但它很有用,爲什麼不呢?
我建議你看看pattern 3 in this article並建立封裝形式存儲的內容,確認他們和發送實際的電子郵件的過程中的表單模型(Notification
?)。請注意,文章中的實現已經過時了,Rails 4引入了ActiveModel::Model
來促進這個過程。
優點:
- 在聲明樣式大多定義另一個類,方便閱讀和查找
- 可以通過SimpleForm或Rails的形式傭工來容易且乾淨奠定了
- 獲取所有傳統Rails模型的好處,如驗證(如果失敗,則會出錯)
- 語義,代碼看起來與使用數據庫或其他應用程序的其他應用程序一致
個
缺點:
- 另一類,可視爲過度設計
- 更多的代碼,更多的工作,易於維護是值得商榷
- 另一目的在於使這種形式的控制器創建
一旦完成,使其工作的過程與使其他資源工作的過程幾乎相同。我假設,這個郵件程序位於單獨的頁面上。
路線:
resource :notification, only: [:create] do
get :new, path: "" # A matter of taste, really
# You may use the default `new` route
# with a path `notifications/new`
end
控制器:
class NotificationsController
def new
@notification = Notification.new
end
def create
@notification = Notification.new(notification_params)
if @notification.send
# success! redirect somewhere?
else
render :new # render the form again with the errors
end
end
private
def notification_params
params.require(:notification).permit(:email, :subject, :body)
end
end
您還需要爲new
的行動,呈現@notification
爲形式的視圖。只有new
,創建並不需要它自己的。而現在最有趣的部分,型號:
class Notification # Yep, it inherits nothing!
include ActiveModel::Model
attr_reader :email, :subject, :body
validates :email,
presence: true # You might want to validate its format?
validates :subject,
presence: true, length: {in: 0..100} # Too long subjects are annoying
validates :body,
presence: true
def persisted?
false # I have no idea why, but it's defined in the article, no harm done
# I'd love to hear the explaination about this though
end
def send
if valid? # no objections from validations?
# Alright, send it already!
Notifier.send_mail(email, subject, body).deliver
# thanks for this line go to @Daniel and his answer
true
else
false
end
end
end
最後,PRO提示:Rails的4.2(前沿馬上!)推出ActiveJob,一個與郵件程序集成。通過調用deliver
方法,並調用deliver_later
,您將按照here (edge guides, subject to change quite soon)所述的順序將後臺任務處理器發送的電子郵件排入隊列。我並不認爲現在是時候在任何地方使用它(太新了),但考慮到未來的項目。
我真的認爲這很好嗎?是的,我真的這樣做,我已經重構了一個用戶密碼更改器,以這種方式來看,代碼變得更容易導航和查看。
這看起來沒錯..已經開始實施它了謝謝 – 2014-11-22 21:37:12