Hi, for some models I found that it''s easier to share the controller new and update code just to share the view code. At the front of every such action function I have to lookup if the object already exists, if so "find" it from the database and update the "attributes=". If there is no such object, "new" it with the attributes I''ve got from the form. After I''ve wrote such code the third time, I came up with this more general solution: class ActiveRecord::Base def Base.find_for_create_modify(key, params) old_one = find(key) unless key.nil? if old_one result = find key result.attributes= params else result = new params end [result, old_one] end end But I think, I can''t be the first one, facing this problem. So I wonder if there might be a more ruby/rails-ish way to accomplish this. best regards Torsten
On 5/27/06, Torsten Robitzki <rails@robitzki.de> wrote:> Hi, > for some models I found that it''s easier to share the controller new and > update code just to share the view code. At the front of every such > action function I have to lookup if the object already exists, if so > "find" it from the database and update the "attributes=". If there is no > such object, "new" it with the attributes I''ve got from the form. > > After I''ve wrote such code the third time, I came up with this more > general solution: > > class ActiveRecord::Base > def Base.find_for_create_modify(key, params) > old_one = find(key) unless key.nil? > if old_one > result = find key > result.attributes= params > else > result = new params > end > > [result, old_one] > end > end > > But I think, I can''t be the first one, facing this problem. So I wonder > if there might be a more ruby/rails-ish way to accomplish this. > > best regards > Torsten > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >Hi Torsten I don''t think the pattern you describe should be that common. Creating a new record and updating an existing record are very different operations. I don''t think it''s healthy to abstract that difference out of your code like that. More concretely, I believe #create and #update should be generally distinct controller actions. It is possible that action #foo would create or update, but then I''d do it with explicit code that informed the surrounding logic whether create or update were performed (can be easily done with a controller helper). Your method prevents that, and I don''t think it''s a good idea. You can of course rewrite the Model method to at least provide that info, but I still think the whole thing should be dealt with at the Controller domain, not hidden inside the Model. -- -Alder
Alder Green wrote:> Hi TorstenHi Alder, thanks for replying.> I don''t think the pattern you describe should be that common. Creating > a new record and updating an existing record are very different > operations. I don''t think it''s healthy to abstract that difference out > of your code like that.Where I see the most common in the implementation of both an update and a create function is in the view code. So maybe I should try to use the same view code for two different controller actions.> More concretely, I believe #create and #update should be generally > distinct controller actions. It is possible that action #foo would > create or update, but then I''d do it with explicit code that informed > the surrounding logic whether create or update were performed (can be > easily done with a controller helper). Your method prevents that, and > I don''t think it''s a good idea.Actually the function returns both the new or updated object and if any, the value of the old object. > You can of course rewrite the Model> method to at least provide that info, but I still think the whole > thing should be dealt with at the Controller domain, not hidden inside > the Model.Point taken. thanks and best regards Torsten