CRUD or not CRUD, I am so lost !
Nicjac
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/.
Ian Leitch
I found reading the source of Mephisto blog helped me a lot
http://mephistoblog.com/
Piotr Chmolowski
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 ;-)
Nicjac
registration/authentication system with a CRUD-only application ?
Specially the mail account activation...
Thanks !
Nicolas Jaccard
Ian Leitch
Go ahead and implement the features you want, CRUD are just convenience functions.
Peter Michaux
> 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
NeilW
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.
Peter Michaux
>
> 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.
Ian Leitch
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.
DHH
> 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.
Daniel N
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 Werner
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.
--
- Nic
Peter Michaux
>
> 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
DHH
> 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.
Peter Michaux
Thanks for the reply and the examples.
On 9/4/06, DHH <david.he...@gmail.com> 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
Daniel N
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
Joe Ruby
in Rails Recipes that combines the create, new, edit, and update actions
all into one. Pretty slick - I like code reduction like that.
Joe
Nicolas Jaccard
!
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
Stephen Bartholomew
would in most cases use the User model.
Steve
DHH
> 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.
Bosko Milekic
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....@gmail.com>
http://www.crowdedweb.com/