Hello, I have recently started learning RoR. I think it''s _fantastic_. I am absolutely blown away. OK, this is to prepare you to my idiotic question. Hopefully, I won''t be stoned. I am designing a simple application, where users can register, and: * Publish a photo album * Publish a simple blog with comments * Determine their list of friends and foes The application will obviously have a front end and a backend. The front end will give people a chance to search, and "find" members and blogs The back end will allow people to manage their profiles and add blog entries. Now: I like the idea of urls like this: domain.com/user/merc/blog Where: * "user" is the controller * "merc" is the user id * "blog" is the action (in this case, show the blog) The backend could be: domain.com/backend/merc/blog Where everything is as above, a part from the fact that "backend" is the controller. This does mean that each controller will have quite a few actions. I guess my question is: how do you decide what a "controller" is and does? How should I divide the application amongst several controllers? Well... I hope I didn''t embarrass myself too much. Thanks a lot and bye! Merc.
Hey Tony ! You should get the Agile Rails Book, and read it too :) Creating a logical controller structure if pretty darn easy... for instance, some of my controllers are: admin_controller.rb, animal_controller.rb, blog_controller.rb It all makes sense when you read the book, and most importantly, start getting your hands dirty creating your application ! Have fun too ! =Dylan On 2/26/06, Tony Mobily <merc@mobily.com> wrote:> > Hello, > > I have recently started learning RoR. I think it''s _fantastic_. I am > absolutely blown away. > OK, this is to prepare you to my idiotic question. Hopefully, I won''t > be stoned. > > I am designing a simple application, where users can register, and: > > * Publish a photo album > * Publish a simple blog with comments > * Determine their list of friends and foes > > The application will obviously have a front end and a backend. > The front end will give people a chance to search, and "find" members > and blogs > The back end will allow people to manage their profiles and add blog > entries. > > Now: I like the idea of urls like this: > > domain.com/user/merc/blog > > Where: > * "user" is the controller > * "merc" is the user id > * "blog" is the action (in this case, show the blog) > > The backend could be: > > domain.com/backend/merc/blog > > Where everything is as above, a part from the fact that "backend" is > the controller. > > This does mean that each controller will have quite a few actions. > > I guess my question is: how do you decide what a "controller" is and > does? How should I divide the application amongst several controllers? > > Well... I hope I didn''t embarrass myself too much. > > Thanks a lot and bye! > > Merc. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060227/2cdf13c4/attachment.html
Tony Mobily wrote:> Hello, > > I have recently started learning RoR. I think it''s _fantastic_. I am > absolutely blown away. > OK, this is to prepare you to my idiotic question. Hopefully, I won''t > be stoned. > > I am designing a simple application, where users can register, and: > > * Publish a photo album > * Publish a simple blog with comments > * Determine their list of friends and foes > > The application will obviously have a front end and a backend. > The front end will give people a chance to search, and "find" members > and blogs > The back end will allow people to manage their profiles and add blog > entries. > > Now: I like the idea of urls like this: > > domain.com/user/merc/blog > > Where: > * "user" is the controller > * "merc" is the user id > * "blog" is the action (in this case, show the blog) > > The backend could be: > > domain.com/backend/merc/blog > > Where everything is as above, a part from the fact that "backend" is > the controller. > > This does mean that each controller will have quite a few actions. > > I guess my question is: how do you decide what a "controller" is and > does? How should I divide the application amongst several controllers? > > Well... I hope I didn''t embarrass myself too much. > > Thanks a lot and bye! > > Merc.The functionality you need can be found in config/routes.rb. I''m abolutely no Rails expert, and I have no idea if the following will work, but try it out anyways: map.connect "backend/:name/blog", :controller => "backend", :action => "blog" or maybe you could just do something like map.connect ":controller/:id/:action" Hope this helped and sorry if it screwed anything up, --Evan -- Posted via http://www.ruby-forum.com/.
Hi, First of all: thanks a lot for your answer!> You should get the Agile Rails Book, and read it too :)Wooops... I am up to page 100 with that one! (And I still don''t get it. Shame on me!)> Creating a logical controller structure if pretty darn easy... for > instance, some of my controllers are: > admin_controller.rb, animal_controller.rb, blog_controller.rbOK! My "problem" is that I don''t get when it makes sense logically to create a controller. Is it meant to control the contents of a specific table? For example, if I create the controller "user", I would like these URLs to work: /user/merc/blog/ (controller is "user", ID is "merc", action is "blog" /user/merc/gallery /user/merc/friends_and_foes /user/merc/leave_message This is for the front-end. Does creating such a controller make sense? This controller wouldn''t manage a specific table. It would fetch data from several tables, for the user. As far as the back-end, shall I have one controller per functionality? Or one controller to manage lock, stock and barrel? For example, do I want to create a controller "backend", which does: /backend/blogs <--- Show the blog entries. Action: /backend/blog_entry_add <--- Add a blog entry [...] /backend/images_list <---- Show the list of images /backend/image_upload <---- Allow the upload of an image Or shall I create several controllers? Like this: /blog/merc/list (controller "blog", ID "merc", action "list") /blog/merc/add /blog/merc/delete /blog/merc/edit [...] /images/merc/list (controller "images", ID "merc", action "list" /images/merc/add /images/merc/delete /images/merc/edit [...] Then, I can use the route mechanism to reroute things so that I can do: /backend/blog/merc/add (controller "blog", ID "merc", action "add") So that I keep the URLs clean. Would this make sense? What''s the philosophy of what controllers should be there? What is a controller from a "logical" point of view? Shall I think of a controller as a module that deals with one specific table? Thanks a million and bye! Merc> It all makes sense when you read the book, and most importantly, > start getting your hands dirty creating your application ! > > Have fun too ! > => Dylan > > > On 2/26/06, Tony Mobily <merc@mobily.com> wrote: Hello, > > I have recently started learning RoR. I think it''s _fantastic_. I am > absolutely blown away. > OK, this is to prepare you to my idiotic question. Hopefully, I won''t > be stoned. > > I am designing a simple application, where users can register, and: > > * Publish a photo album > * Publish a simple blog with comments > * Determine their list of friends and foes > > The application will obviously have a front end and a backend. > The front end will give people a chance to search, and "find" members > and blogs > The back end will allow people to manage their profiles and add blog > entries. > > Now: I like the idea of urls like this: > > domain.com/user/merc/blog > > Where: > * "user" is the controller > * "merc" is the user id > * "blog" is the action (in this case, show the blog) > > The backend could be: > > domain.com/backend/merc/blog > > Where everything is as above, a part from the fact that "backend" is > the controller. > > This does mean that each controller will have quite a few actions. > > I guess my question is: how do you decide what a "controller" is and > does? How should I divide the application amongst several controllers? > > Well... I hope I didn''t embarrass myself too much. > > Thanks a lot and bye! > > Merc. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Often (not always), your controllers are in sync with your table names. If you have a "users" table, you''ll have a user_controller.rb A URL such as /user/edit/13 would invoke the "edit" function under user_controller.rb, and would typically be used to edit the entry in the users table with id=13. The "edit" function may look like: class UserController ... def edit @user = User.find(params[:id]) end You would then have an edit.rhtml, which would be rendered by default when the edit function exits (note that the *edit* function renders *edit*.rhtml by default; it can be changed, but I try not to change it unless I have to for the sake of simplicity). It may contain stuff like <html> ... <p>User name: <%= @user.name %></p> <p>User email: <%= @user.email %></p> </html> where @user has been populated by the edit function in user_controller.rb That''s basically how the MVC stuff works; you can override it, extend it, tweak it to your heart''s content, but that''s essentially. As to when you need to define a "new" controller, as I said it often makes sense to start from a premise of one per table as the "default" and go forward from there. This is particularly the case where the users interact more or less directly with tables (e.g. user creates an order; it goes directly into the "orders" table), but may be less applicable where user activities are less directly linked to specific tables. Some tables don''t need to be explicitly populated by users doing stuff, or may be populated as a result of users changing data in other tables - in this case, it may not make sense to create controllers for these tables. Alternately, you might e.g. define a controller named "reports" (even when you don''t have a table named "reports"), and drive all the report generation stuff for your entire application through the "reports" controller. You might want a controller named "login", and route all By and large, most apps will break down into logical chunks of functionality (e.g. login, reporting, data entry/maintenance on a per-table basis, etc.) and these would tend to be mirrored one "chunk" per controller. I realise that''s a bit vague; does anyone else want to take a shot at it? Regards Dave M. On 27/02/06, Tony Mobily <merc@mobily.com> wrote:> Hi, > > First of all: thanks a lot for your answer! > > > You should get the Agile Rails Book, and read it too :) > > Wooops... I am up to page 100 with that one! > (And I still don''t get it. Shame on me!) > > > Creating a logical controller structure if pretty darn easy... for > > instance, some of my controllers are: > > admin_controller.rb, animal_controller.rb, blog_controller.rb > > OK! > My "problem" is that I don''t get when it makes sense logically to > create a controller. > Is it meant to control the contents of a specific table? > For example, if I create the controller "user", I would like these > URLs to work: > > /user/merc/blog/ (controller is "user", ID is "merc", action is "blog" > /user/merc/gallery > /user/merc/friends_and_foes > /user/merc/leave_message > > This is for the front-end. Does creating such a controller make > sense? This controller wouldn''t manage a specific table. It would > fetch data from several tables, for the user. > > As far as the back-end, shall I have one controller per > functionality? Or one controller to manage lock, stock and barrel? > For example, do I want to create a controller "backend", which does: > > /backend/blogs <--- Show the blog entries. Action: > /backend/blog_entry_add <--- Add a blog entry > [...] > /backend/images_list <---- Show the list of images > /backend/image_upload <---- Allow the upload of an image > > Or shall I create several controllers? > Like this: > > /blog/merc/list (controller "blog", ID "merc", action "list") > /blog/merc/add > /blog/merc/delete > /blog/merc/edit > [...] > /images/merc/list (controller "images", ID "merc", action "list" > /images/merc/add > /images/merc/delete > /images/merc/edit > [...] > > Then, I can use the route mechanism to reroute things so that I can do: > > /backend/blog/merc/add (controller "blog", ID "merc", action "add") > > So that I keep the URLs clean. > > Would this make sense? > > What''s the philosophy of what controllers should be there? What is a > controller from a "logical" point of view? Shall I think of a > controller as a module that deals with one specific table? > > Thanks a million and bye! > > Merc > > > It all makes sense when you read the book, and most importantly, > > start getting your hands dirty creating your application ! > > > > Have fun too ! > > => > Dylan > > > > > > On 2/26/06, Tony Mobily <merc@mobily.com> wrote: Hello, > > > > I have recently started learning RoR. I think it''s _fantastic_. I am > > absolutely blown away. > > OK, this is to prepare you to my idiotic question. Hopefully, I won''t > > be stoned. > > > > I am designing a simple application, where users can register, and: > > > > * Publish a photo album > > * Publish a simple blog with comments > > * Determine their list of friends and foes > > > > The application will obviously have a front end and a backend. > > The front end will give people a chance to search, and "find" members > > and blogs > > The back end will allow people to manage their profiles and add blog > > entries. > > > > Now: I like the idea of urls like this: > > > > domain.com/user/merc/blog > > > > Where: > > * "user" is the controller > > * "merc" is the user id > > * "blog" is the action (in this case, show the blog) > > > > The backend could be: > > > > domain.com/backend/merc/blog > > > > Where everything is as above, a part from the fact that "backend" is > > the controller. > > > > This does mean that each controller will have quite a few actions. > > > > I guess my question is: how do you decide what a "controller" is and > > does? How should I divide the application amongst several controllers? > > > > Well... I hope I didn''t embarrass myself too much. > > > > Thanks a lot and bye! > > > > Merc. > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >