CRUD or not CRUD, I am so lost !

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.

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.

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

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.

Hi David,

Thanks for the reply and the examples.

> 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

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

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

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?