Rails - Jul 2008 - Restful Paradigm: How do I know when to create a new controller?

I''ve read a lot of articles and tutorials about how to use Rest, but
one thing I haven''t seen in many of them is when to create
controllers. In many cases I have controllers with only 1 method in
them (usually a create), and I''m stuck wondering if it''s ok
like that
or if it should be a custom method inside another controller that has
a close relationship (usually a has_many) with it.

Also, how do I know when I''m correctly following the Restful paradigm?
I''ve learned how to do it, but I haven''t learned the theory
behind it
or anything like that. Any help would be appreciated, thanks.
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---

Difficult question. In some cases it''s more a matter of
taste, if you prefer the "canonical" way and have a file
more or if you like it more "compact".
In our company we would most likely create a controller,
whenever one of the CRUD actions can be applied to
a resource.
The rough rule table = resource = controller works quite
well most of the time and you know what to expect from
the code. Have a products table? It will be mainly handled
in the products controller. (The resource/route for it most
likely nested in the "categories" resources if we have one.

Only some minor and directly related methods stay in the
controller, especially the non-crud kind like if you have invoices
the print, write-pdf, book, export, cancel or whatever.

That''s only rough rules of course. But it works, especially in a team.
Just don''t think much about it, create the controller and everybody
knows where to look for what.
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---

+1 Müller

On Jul 3, 9:39 am, Thorsten Müller
<thors...-1oxKqHKwyltBDgjK7y7TUQ@public.gmane.org>
wrote:
> Difficult question. In some cases it''s more a matter of
> taste, if you prefer the "canonical" way and have a file
> more or if you like it more "compact".
> In our company we would most likely create a controller,
> whenever one of the CRUD actions can be applied to
> a resource.
> The rough rule table = resource = controller works quite
> well most of the time and you know what to expect from
> the code. Have a products table? It will be mainly handled
> in the products controller. (The resource/route for it most
> likely nested in the "categories" resources if we have one.
>
> Only some minor and directly related methods stay in the
> controller, especially the non-crud kind like if you have invoices
> the print, write-pdf, book, export, cancel or whatever.
>
> That''s only rough rules of course. But it works, especially in a
team.
> Just don''t think much about it, create the controller and
everybody
> knows where to look for what.
--~--~---------~--~----~------------~-------~--~----~
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@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi --

On Thu, 3 Jul 2008, Mike C wrote:
> I''ve read a lot of articles and tutorials about how to use Rest,
but
> one thing I haven''t seen in many of them is when to create
> controllers. In many cases I have controllers with only 1 method in
> them (usually a create), and I''m stuck wondering if it''s
ok like that
> or if it should be a custom method inside another controller that has
> a close relationship (usually a has_many) with it.
>
> Also, how do I know when I''m correctly following the Restful
paradigm?
> I''ve learned how to do it, but I haven''t learned the
theory behind it
> or anything like that. Any help would be appreciated, thanks.
If you haven''t already seen them, you might find these interesting:

http://dablog.rubypal.com/2008/3/23/splitting-hairs-over-resource
http://dablog.rubypal.com/2008/4/24/splitting-hairs-over-resource-part-2

They''re about the REST concepts of resource and representation, and
how they map to Rails''s REST-friendly facilities, as well as some
common misunderstandings.


David

-- 
Rails training from David A. Black and Ruby Power and Light:
   Intro to Ruby on Rails  July 21-24      Edison, NJ
   Advancing With Rails    August 18-21    Edison, NJ
See http://www.rubypal.com for details and updates!

--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---

David,

thank you for your post and for the blogs.  Very helpful and timely.

I am working on an area in my app which has made me think very
carefully about how to structure things and how to set up the
routing.  Each time I think more about it I get nearer to a clean
solution.  The thing I think I face is separating the external
consideration of the resource and the representation from the data and
program structure itself.  After reading your blog, I am coming to
realise that these are very separate considerations.

I am writing an office app in which all navigation is based on
buttons, and links.  (Although I guess that is true of most sites
too.)  What this means is that I tend to think more about how to make
something work in the view and how to travel between views without
really considering the aspect of resources.

I have need to extend existing models where customer orders are
received already created from external sources and to now allow local
creation of orders.  Whilst it sounds simple, there are constraints
that have led me to partition the customers/orders.  Hence there are
some parts of the MVC that are shared and some that are distinct.

I find deriving the routing scheme very difficult and am coming to a
suitable solution very slowly.  It just seems to me that there is an
area here for some notation and dare I say it methodology that would
help in the process of mapping from the requirement to the development
of resources and then the mapping through the routing to the
application and structure.  I sense there could even be template
solutions that could fit a wide range of requirements and that there
are a lot of us out there at the moment sweating over  similar
problems.  I guess it will begin to fall into place in time.  Blogs
like yours do help.

As an aside, once I have created the routes, I do not always find the
the use of the path and url methods  terribly intuitive.  We have rake
routes, and I was wondering if there might be any way to generate the
formats available for path and url methods for a resource or group of
resources.

Tonypm


--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---

Ok - so I was talking nonsense.  The path/url method format is in rake
routes display too.
> As an aside, once I have created the routes, I do not always find the
> the use of the path and url methods  terribly intuitive.  We have rake
> routes, and I was wondering if there might be any way to generate the
> formats available for path and url methods for a resource or group of
> resources.
>
> Tonypm
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---