Hello all, I have been working with rails for a few days, getting amazed everyday how everything is made so I only have to think about the important stuff. But I still have some doubts about the "Rails way of doing things", specially after watching David''s keynote. My application relies alot on users. I have a UserController which take care of all the registration, password changes, etc.. but is not really designed around the CRUD idea. I have methods like registration, registration_confirmation, etc.. Now in my Admin::UserController I have pure CRUD methods. Because it''s the admin side, it''s just more easier to stick with that "philosophy". Do I have something wrong here ? Should main controllers of the app be based around CRUD as well or it only applies to pure database tasks as administrating users ? Should my administrative part be included in the "public" UserController, if so, how ? Thanks in advance ! Nicolas Jaccard -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
No, it''s fine for your public controllers to not scaffold, you need to ensure the right user is performing them etc.. I found reading the source of Mephisto blog helped me a lot http://mephistoblog.com/ On 03/09/06, Nicjac <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > > Hello all, > I have been working with rails for a few days, getting amazed everyday > how everything is made so I only have to think about the important > stuff. > But I still have some doubts about the "Rails way of doing things", > specially after watching David''s keynote. > > My application relies alot on users. I have a UserController which take > care of all the registration, password changes, etc.. but is not really > designed around the CRUD idea. I have methods like registration, > registration_confirmation, etc.. > > Now in my Admin::UserController I have pure CRUD methods. Because it''s > the admin side, it''s just more easier to stick with that "philosophy". > > Do I have something wrong here ? Should main controllers of the app be > based around CRUD as well or it only applies to pure database tasks as > administrating users ? Should my administrative part be included in the > "public" UserController, if so, how ? > > > Thanks in advance ! > > > Nicolas Jaccard > > > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
From my personal experience I can say that it''s not always possible to design your app to be 100% CRUD-ish. I''ve redesigned the whole code, added a bunch of new controllers and models to better organize the application, but there''re still a lot of actions that simply can''t be converted into CRUD. Listen to David''s keynote once again, try to find some blog posts on the subject and then try to think again about the structure of your app - if you feel that certain actions can''t be removed/converted to crud-controllers, stick with what you have. It doesn''t violate the Rails philosophy ;-) -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Ok but I am really curious, how would one have a complete registration/authentication system with a CRUD-only application ? Specially the mail account activation... Thanks ! Nicolas Jaccard -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
It seems you misunderstand what CRUD is. CRUD isn''t a design concept, it''s just a term used to indicate something provides the basic operations to perform Create, Retrieve, Update and Delete for you. A CRUD-only application can''t have authentication, or anything other than create, retrieve, update or delete for that matter. Go ahead and implement the features you want, CRUD are just convenience functions. On 03/09/06, Nicjac <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > > Ok but I am really curious, how would one have a complete > registration/authentication system with a CRUD-only application ? > Specially the mail account activation... > > > Thanks ! > > > > > Nicolas Jaccard > > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On 9/3/06, Ian Leitch <port001-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> It seems you misunderstand what CRUD is. CRUD isn''t a design concept, it''s > just a term used to indicate something provides the basic operations to > perform Create, Retrieve, Update and Delete for you. A CRUD-only application > can''t have authentication,In the Rails core Q&A video from the conference DHH said Jamis Buck argued persuasively against this. I think it goes login POST /session/create logout DELETE /session/destroy People have also argued that search can be CRUD. http://blog.hasmanythrough.com/articles/2006/06/30/cruddy-searches It doesn''t mean these are the best way to do things but people are thinking about CRUD creatively. Peter> or anything other than create, retrieve, update > or delete for that matter. > > Go ahead and implement the features you want, CRUD are just convenience > functions. > > > On 03/09/06, Nicjac < rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> > wrote: > > > > Ok but I am really curious, how would one have a complete > > registration/authentication system with a CRUD-only application ? > > Specially the mail account activation... > > > > > > Thanks ! > > > > > > > > > > Nicolas Jaccard > > > > -- > > Posted via http://www.ruby-forum.com/. > > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
All actions can be converted to CRUD, just as all programs can be converted to ones without GOTOs in them. The question is merely whether it is sensible to do so, or whether to use an aspect on a different controller. --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On 9/4/06, NeilW <aldursys-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > All actions can be converted to CRUD, just as all programs can be > converted to ones without GOTOs in them.Interesting that this analogy almost implies converting to CRUD is judged to be as fundamental to good programming as removing all GOTO statements.> The question is merely whether it is sensible to do so, or whether to > use an aspect on a different controller.--~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
The downsides of GOTO are a lot more apparent than not using CRUD, I''d even go as far as saying there aren''t any downsides to not using CRUD, it''s just a different approach. CRUD does put a new light on a lot of traditional methods but I don''t think it''s something people should go applying to every part of their code. It seems to me to CRUD has escalated into something more than it really is. Whereas it just used to be a handy feature for frameworks, now its evolved into a design pattern. Just a bit too much hype for my liking. On 04/09/06, Peter Michaux <petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > On 9/4/06, NeilW <aldursys-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > All actions can be converted to CRUD, just as all programs can be > > converted to ones without GOTOs in them. > > Interesting that this analogy almost implies converting to CRUD is > judged to be as fundamental to good programming as removing all GOTO > statements. > > > > > The question is merely whether it is sensible to do so, or whether to > > use an aspect on a different controller. > > > >--~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
> My application relies alot on users. I have a UserController which take > care of all the registration, password changes, etc.. but is not really > designed around the CRUD idea. I have methods like registration, > registration_confirmation, etc..That''s the money shot right there. Your domain needs to include these concepts explicitly. Treat Registration as a model. Perhaps even Confirmation (or it could be a state of Registration). In Campfire, we have a class called Invitation to handle a similar issue. You can then crud on the Invitation (or the Registration in your case) and all is cherry. --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On 9/5/06, DHH <david.heinemeier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > > My application relies alot on users. I have a UserController which take > > care of all the registration, password changes, etc.. but is not really > > designed around the CRUD idea. I have methods like registration, > > registration_confirmation, etc.. > > That''s the money shot right there. Your domain needs to include these > concepts explicitly. Treat Registration as a model. Perhaps even > Confirmation (or it could be a state of Registration). > > In Campfire, we have a class called Invitation to handle a similar > issue. You can then crud on the Invitation (or the Registration in your > case) and all is cherry.To achieve registration and invitation as their own models, do you use corresponding tables for this? Should all non-CRUD specific actions spawn another model and table to cooerce it into CRUD? If so, couldn''t this get seriously out of hand and fragment data etc? I''m trying to wrap my head around the true nivarna that is CRUD but I must admit I''m not even close to working out best practice of these types of seemingly simple cases. --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
I''m going to probably put my foot in my mouth here and respond with MY BELIEF: What DHH is talking about w/the CRUD concept is that if you really break down your application and looks at its pieces, you''ll see that each component would fit the CRUD component. - This is like Smalltalk saying everything is a message - This is like any language that is Object-Oriented - look closely enough and everything is an object! - Java uses getters and setters for classes, which can be objects. And with those objects, what do you do? You Create new ones, Update old ones, Read and Delete them. What DHH is saying about CRUD is nothing new, what I got from the presentation is that he is pointing out how *well* this couples in the web environment, with its different layers, and how this is a good rule of thumb for working on your model: Ex: I want to Read something about an object --> Use GET I want to Update someting about an object --> Use POST DHH gave you an example for your context, Registration. You''ll want to create new ones, delete existing etc. When I''m stumped about trying to fit a ''concept'' into programming, I think of the verbs that entailed. What is the User doing? ''The user is *authenticating* to my program.'', ''The user is *registering* for an Event'' Feel free to correct me anyone, my main point was that you shouldn''t think of this as the mantra for your life, just take note of how well it couples with the other layers and follow it as a guideline. - Nic. On 9/4/06, Daniel N <has.sox-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > > On 9/5/06, DHH <david.heinemeier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > My application relies alot on users. I have a UserController which take > > > care of all the registration, password changes, etc.. but is not really > > > designed around the CRUD idea. I have methods like registration, > > > registration_confirmation, etc.. > > > > That''s the money shot right there. Your domain needs to include these > > concepts explicitly. Treat Registration as a model. Perhaps even > > Confirmation (or it could be a state of Registration). > > > > In Campfire, we have a class called Invitation to handle a similar > > issue. You can then crud on the Invitation (or the Registration in your > > case) and all is cherry. > > > > To achieve registration and invitation as their own models, do you use > corresponding tables for this? > > Should all non-CRUD specific actions spawn another model and table to > cooerce it into CRUD? If so, couldn''t this get seriously out of hand and > fragment data etc? > > I''m trying to wrap my head around the true nivarna that is CRUD but I must > admit I''m not even close to working out best practice of these types of > seemingly simple cases. > > > > > >-- - Nic --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On 9/4/06, Nic Werner <nicwerner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > I''m going to probably put my foot in my mouth here and respond with MY BELIEF: > > What DHH is talking about w/the CRUD concept is that if you really > break down your application and looks at its pieces, you''ll see that > each component would fit the CRUD component.[snip]> Feel free to correct me anyone, my main point was that you shouldn''t > think of this as the mantra for your life, just take note of how well > it couples with the other layers and follow it as a guideline.When Rails 2.0 is releases, I would really like and hope to see a tutorial of a small app (eg Agile Web Rails Depot app?) that has registration, authentication and search done in CRUD fashion. Seeing a few edge cases would show how CRUD fits so well in the web/Rails environment. I think that would really jumpstart a lot of people into _thinking_ CRUD. Peter --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
> When Rails 2.0 is releases, I would really like and hope to see a > tutorial of a small app (eg Agile Web Rails Depot app?) that has > registration, authentication and search done in CRUD fashion. Seeing a > few edge cases would show how CRUD fits so well in the web/Rails > environment. I think that would really jumpstart a lot of people into > _thinking_ CRUD.All the crudification is going to ship in Rails 1.2, so that would indeed be a good time to do a good introduction on How to Crud. I''ll give the ultra sort version here on your pieces: 1) Registration: If you have delayed registration (you invite someone to join the app, they then do stuff), it should be its own model (Invitation or something like that). If you have real-time registration, just crud on the primary model. That might be User or it might be Account. 2) Authentication: I don''t consider this a crud-worthy pursuit. For REST web services, you''re going to use HTTP auth anyway. It''s not part of the domain (but rather its part of the interface). So I currently have AuthenticationController#login for form-based login and HTTP auth for the web services. 3) Search: Unless your app require logging, it''s not a model in itself. I''d consider /people?first_name=David a search. In other words, searching is just parameters on an existing collection resource. If you use GET, it''s also a bookmarkable URL, which is very cool. I hate searches that use POST. There are still lots of corner cases, though. When something fits the crud well or not. I gave a few examples on ambiguities and non-CRUD methods in the RailsConf presentation. But since then I''ve been surprised at just how well the concept fits. It''s not a 80/20 thing, it''s more like a 95/5 thing. --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Hi David, Thanks for the reply and the examples. On 9/4/06, DHH <david.heinemeier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > When Rails 2.0 is releases, I would really like and hope to see a > > tutorial of a small app (eg Agile Web Rails Depot app?) that has > > registration, authentication and search done in CRUD fashion. Seeing a > > few edge cases would show how CRUD fits so well in the web/Rails > > environment. I think that would really jumpstart a lot of people into > > _thinking_ CRUD. > > All the crudification is going to ship in Rails 1.2, so that would > indeed be a good time to do a good introduction on How to Crud.I''m looking forward to reading it whoever writes it.> I''ll give the ultra sort version here on your pieces: > > 1) Registration: If you have delayed registration (you invite someone > to join the app, they then do stuff), it should be its own model > (Invitation or something like that). If you have real-time > registration, just crud on the primary model. That might be User or it > might be Account. > > 2) Authentication: I don''t consider this a crud-worthy pursuit. For > REST web services, you''re going to use HTTP auth anyway. It''s not part > of the domain (but rather its part of the interface). So I currently > have AuthenticationController#login for form-based login and HTTP auth > for the web services. > > 3) Search: Unless your app require logging, it''s not a model in itself. > I''d consider /people?first_name=David a search. In other words, > searching is just parameters on an existing collection resource. If you > use GET, it''s also a bookmarkable URL, which is very cool. I hate > searches that use POST. > > There are still lots of corner cases, though. When something fits the > crud well or not. I gave a few examples on ambiguities and non-CRUD > methods in the RailsConf presentation. But since then I''ve been > surprised at just how well the concept fits. It''s not a 80/20 thing, > it''s more like a 95/5 thing.95/5 is really big and that''s why I''m so interested to get a peek into other peoples brains about how they implement the details the strange cases. It seems like converting people to CRUD might have some of the same obsticals that converting to OOP had and require a little evangelism. Thanks again, Peter --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On 9/5/06, DHH <david.heinemeier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > > When Rails 2.0 is releases, I would really like and hope to see a > > tutorial of a small app (eg Agile Web Rails Depot app?) that has > > registration, authentication and search done in CRUD fashion. Seeing a > > few edge cases would show how CRUD fits so well in the web/Rails > > environment. I think that would really jumpstart a lot of people into > > _thinking_ CRUD. > > All the crudification is going to ship in Rails 1.2, so that would > indeed be a good time to do a good introduction on How to Crud. I''ll > give the ultra sort version here on your pieces: > > 1) Registration: If you have delayed registration (you invite someone > to join the app, they then do stuff), it should be its own model > (Invitation or something like that). If you have real-time > registration, just crud on the primary model. That might be User or it > might be Account. > > 2) Authentication: I don''t consider this a crud-worthy pursuit. For > REST web services, you''re going to use HTTP auth anyway. It''s not part > of the domain (but rather its part of the interface). So I currently > have AuthenticationController#login for form-based login and HTTP auth > for the web services. > > 3) Search: Unless your app require logging, it''s not a model in itself. > I''d consider /people?first_name=David a search. In other words, > searching is just parameters on an existing collection resource. If you > use GET, it''s also a bookmarkable URL, which is very cool. I hate > searches that use POST. > > There are still lots of corner cases, though. When something fits the > crud well or not. I gave a few examples on ambiguities and non-CRUD > methods in the RailsConf presentation. But since then I''ve been > surprised at just how well the concept fits. It''s not a 80/20 thing, > it''s more like a 95/5 thing. > > > Thanx for the information David.I really want to understand REST/CRUD for apps since this is such a strong direction for Rails. I''m looking forward to the How to Crud with 1.2. Cheers --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
I''m not so sure about CRUD - there''s a really concise recipe by Marcel in Rails Recipes that combines the create, new, edit, and update actions all into one. Pretty slick - I like code reduction like that. Joe -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Nice to see a good discussion going about CRUD, I am not so lost anymore ! I have a question about using a model for everything. Let''s say I have a model called ''invitation'' to represent the mail I send to a user to confirm his registration. It means that I have to create an ''invitationController'' so I can implement the CRUD functions. Does it mean that I am going to have one controller per model ? Having one model for all relations is going to be lot of files, adding one controller per model is just going to be way too much. As it was asked earlier, is the CRUD philosophy really worth all the files it generates ? Nicolas Jaccard -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
> Does it mean that I am going to have one controller per model ?I don''t see why you should. Think of the AuthenticationController - it would in most cases use the User model. Steve --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
> Does it mean that I am going to have one controller per model ? Having > one model for all relations is going to be lot of files, adding one > controller per model is just going to be way too much. As it was asked > earlier, is the CRUD philosophy really worth all the files it generates?What''s the perceived price of many files? To me, it''s much simpler to deal with 5 files that each have 5 methods than 2 files that each has 12. Also, you don''t need one model per relationship, if you''re thinking that a relationship is an association. Only for many-to-many relationships. So an Authorship model to link Author and Book, but no model to link Post has_many :comments. --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On 9/5/06, DHH <david.heinemeier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > Does it mean that I am going to have one controller per model ? Having > > one model for all relations is going to be lot of files, adding one > > controller per model is just going to be way too much. As it was asked > > earlier, is the CRUD philosophy really worth all the files it generates? > > What''s the perceived price of many files? To me, it''s much simpler to > deal with 5 files that each have 5 methods than 2 files that each has > 12. Also, you don''t need one model per relationship, if you''re thinking > that a relationship is an association. Only for many-to-many > relationships. So an Authorship model to link Author and Book, but no > model to link Post has_many :comments.My one beef with completely-CRUD is that in one of my more involved Rails applications I have several callpaths that end up requiring an Update on a particular model, but from different view contexts (and so a PUT /foos/1 on the corresponding model controller, a few times, each time from a different view structure). My beef is with the fact that ActionPack in its current form tightly couples action and view, and while respond_to handles the content-type split well, it still doesn''t allow me to cleanly separate out views for a particular action, such as Update in my example. The best solution I could find here is Bruce Williams'' context plugin (http://codefluency.com/articles/2006/07/01/rails-views-getting-in-context/), to further decouple view from action where absolutely necessary (note that this is often required for applications where you have one main callpath for a particular entity update, but a second completely different one from, e.g., a streamlined wizard widget in your app). Will context, in its current or similar form, ever end up in core? -- Bosko Milekic <bosko.milekic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> http://www.crowdedweb.com/ --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---