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.
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.
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.
> 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.
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?