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 ?
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…
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
I don’t no the definite answer to your question about the
UserController so that is why the offlist response. Some Rails core
members don’t care much about CRUD and think that contorollers that
are designed around remote procedure call style is fine too.
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.
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 B.
argued persuasively against this. I think it goes
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.
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.
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.
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:
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.
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.
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.
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’m looking forward to reading it whoever writes it.
of the domain (but rather its part of the interface). So I currently
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.
indeed be a good time to do a good introduction on How to Crud. I’ll
of the domain (but rather its part of the interface). So I currently
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 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.
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
?
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.
