2016-11-28 11 views
2

私はEventモデルを持っています。それはbudget paramです。ビジネスロジックを使用するには、budgetが作成時に設定された後には変更できないようにする必要があります。 クライアント側では、これは対応するフィールドを無効にすることを意味します。Railsの異なるパラメータが作成および更新されます

もちろん、このデータは手動でサーバーに送信できます。

def event_params 
    params 
    .require(:event) 
    .permit(
     :title, 
     :budget, 
     ... 
    ) 

そしてevent_params

の作成と更新方法の両方で使用された: は、サーバー上で、事前設定は以下の通りでした。 私は、作成と更新のための2つの異なるパラメータセットを作成することを検討していましたが、DRYのためにこの考えが気に入らないのです。

この質問に対するあなたの提案は何ですか?どのようにコードをエレガントに保ちながら予算を更新するのを防ぐには?

答えて

1

budgetを後で変更できない場合は、更新アクションのパラメータ(など)に:budgetを許可することはできません。これはDRYの違反ではなく、サイトのセキュリティ上の問題です。

例として、deviseが動作する方法を確認します。彼は1つのsign_upのためのパラメータのセットとaccount_update https://github.com/plataformatec/devise/blob/master/app/controllers/devise/registrations_controller.rb#L137

のための別のものを持っている。しかし、あなたが作成および更新の両方に同じパラメータを使用したい場合は、サービスにビジネスロジックを移動することができます。彼らについての素敵な記事は次のとおりです:https://blog.engineyard.com/2014/keeping-your-rails-controllers-dry-with-services

考え方は、作成する方法と更新する方法の両方があるEventServiceを作成することです。各メソッドは、コントローラから受け取った許可されたパラメータを扱います(event_paramsから)

0

提案したように、2つの別々のヘルパーevent_params_for_createevent_params_for_updateを使用することができます。

それらを乾燥させるために、あなたはこの試みることができる:あなたは、その後、たとえば、作成または更新中にそれぞれの方法を使用することになり

def event_params_common 
    [:generic_value_1, :generic_value_2] 
end 

def event_params_for_create 
    event_params_preprocessed 
    .require(:event) 
    .permit(event_params_common.concat([:extra_create_only_param])) 
end 

def event_params_for_update 
    event_params_preprocessed 
    .require(:event) 
    .permit(event_params_common) 
end 

を。

# def create 
@event = Event.new(event_params_for_create) 

# def update 
@event.update(event_params_for_update) 

このようにして、共通フィールドを1回だけ設定しています。

関連する問題