I have a Rails app that is a directory indexer. It passes the desired directory path in the url. There is a user table, and a permissions table (which contains the volumes each user has permission to see). There is also a volume table, which contains the available volumes, and a path table, which contains the paths to every file available on the machine. [There are other tables, but these seem most likely to be useful] Each user has_many permissions. There are many controllers that allow the user to act on files and folders - view them, search them, etc. However, for everything a user can do, the path needs to be checked to make sure he has access privileges. Where should the "path checking" function go, and how should it be called? Is it in the user model, or is it in the application controller, or is it some place else (like a path model)? -- Posted via http://www.ruby-forum.com/.
It could be done either way but just remember that the params variable is not accessable in the model. I would add a module to do the checking. -- Posted via http://www.ruby-forum.com/.
On 7/6/06, Roland Mai <roland.mai@gmail.com> wrote:> It could be done either way but just remember that the params variable > is not accessable in the model. I would add a module to do the checking. >I second that. You might go far enough to have one controller for actions and just do a before_filter that checks the path. Models are almost never the place for code except when it relates only to reading or writing data. This case is certainly muddled but the controller feels better aesthetically to me. Cheers, Chuck Vose
On 7/6/06, Chuck Vose <vosechu@create-on.com> wrote:> > Models are almost never the place for code except when it relates only to > reading > or writing data. This case is certainly muddled but the controller > >Not sure if I agree with that statement. Controllers (according to the MVC pattern) are really only for dealing with the user''s request and sending a response. That''s why views are separated. I would do as much as I could using models and modules and keep my controllers nice and tidy. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060706/de3e59ed/attachment.html
njmacinnes@gmail.com
2006-Jul-06 21:31 UTC
[Rails] Re: Where to put code - controller or model
On 06/07/06, Chuck Vose <vosechu@create-on.com> wrote:> Models are almost never the place for code except when it > relates only to reading or writing data.But the path validation is a type of data. For example, you could store all valid paths in a database table called valid_paths, you could store it (or them) in a text file (valid_paths.txt) or you could hard code it. Either way, this is an example of data, and therefore, is part of the model. I agree with Brian - controllers deal with accepting a request and sending the response. Nothing more. -Nathan
On 07/07/2006, at 2:45 AM, Chuck Vose wrote:> Models are > almost never the place for code except when it relates only to reading > or writing data.Not at all true. The model in MVC is where your domain logic lives. The controller simply acts as glue, handling user events and performing model operations at appropriate. See here: http://en.wikipedia.org/wiki/Model-view-controller Rails strongly follows this pattern and really encourages you to push code down into the model as much as possible. Pete Yandell http://9cays.com/
Andrea Di Clemente
2006-Jul-07 00:46 UTC
[Rails] Re: Where to put code - controller or model
On 07/07/2006, at 2:45 AM, Chuck Vose wrote:> Models are > almost never the place for code except when it relates only to reading > or writing data.In Rails, it''s quite the opposite: use the controller only to setup things you need to display in the view, and nothing more. ciao, Andrea Di Clemente ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
> In Rails, it''s quite the opposite: use the controller only to setup > things you > need to display in the view, and nothing more. > > ciao, > Andrea Di Clemente > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program.Interesting topic. My first rails application (which I''ve just started) will implement a background process that runs constantly as a service. I have decided to start the project with this background service since it is the cornerstone of the application. As such, I have (so far) found myself coding everything in the model. Since this part of the application has no view, I haven''t even touched the controllers yet, saving views and controllers for the interactive portions of the application (user interface, adminstration, reporting, customer control panel, etc.) Since I have never coded an application using an MVC design pattern and I''ve never built a RoR application before, I would be interested to hear the communities views on this. Perhaps I should be taking a slightly different approach. Should a background process that runs as a service leverage controllers? Am I leaning too much on the model for something that doesn''t have a user interface? - Don -- Posted via http://www.ruby-forum.com/.
Don: I believe you are doing things correctly (provided that I understand what you''re doing) Controllers are meant to handle user requests. But you might have some other method that interacts with your moels... another Ruby script that runs via Rake or cron. That''s another point of entry for the application, and that is why you keep business logic in the models, like you''ve done. Sounds like a neat program. On 7/6/06, Don Stocks <amillionhitpoints@yahoo.com> wrote:> > > In Rails, it''s quite the opposite: use the controller only to setup > > things you > > need to display in the view, and nothing more. > > > > ciao, > > Andrea Di Clemente > > > > ---------------------------------------------------------------- > > This message was sent using IMP, the Internet Messaging Program. > > Interesting topic. My first rails application (which I''ve just started) > will implement a background process that runs constantly as a service. > I have decided to start the project with this background service since > it is the cornerstone of the application. As such, I have (so far) > found myself coding everything in the model. Since this part of the > application has no view, I haven''t even touched the controllers yet, > saving views and controllers for the interactive portions of the > application (user interface, adminstration, reporting, customer control > panel, etc.) > > Since I have never coded an application using an MVC design pattern and > I''ve never built a RoR application before, I would be interested to hear > the communities views on this. Perhaps I should be taking a slightly > different approach. > > Should a background process that runs as a service leverage controllers? > Am I leaning too much on the model for something that doesn''t have a > user interface? > > - Don > > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > 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/20060707/a758ab85/attachment.html
Apologies for the counter-current advice. I suppose the way I do things and the way others do things is often different. I also didn''t know much about modules before writing this and I believe that they''re a much better place to code extra logic. I''ve lost track of where the conversation began, just wanted to drop in again and accept my (incredibly sincere and surprisingly pleasant) tongue lashing. Cheers, Chuck Vose On 7/6/06, Brian Hogan <bphogan@gmail.com> wrote:> Don: > > I believe you are doing things correctly (provided that I understand what > you''re doing) > Controllers are meant to handle user requests. But you might have some > other method that interacts with your moels... another Ruby script that runs > via Rake or cron. That''s another point of entry for the application, and > that is why you keep business logic in the models, like you''ve done. > > Sounds like a neat program. > > > On 7/6/06, Don Stocks <amillionhitpoints@yahoo.com> wrote: > > > In Rails, it''s quite the opposite: use the controller only to setup > > > things you > > > need to display in the view, and nothing more. > > > > > > ciao, > > > Andrea Di Clemente > > > > > > > ---------------------------------------------------------------- > > > This message was sent using IMP, the Internet Messaging Program. > > > > Interesting topic. My first rails application (which I''ve just started) > > will implement a background process that runs constantly as a service. > > I have decided to start the project with this background service since > > it is the cornerstone of the application. As such, I have (so far) > > found myself coding everything in the model. Since this part of the > > application has no view, I haven''t even touched the controllers yet, > > saving views and controllers for the interactive portions of the > > application (user interface, adminstration, reporting, customer control > > panel, etc.) > > > > Since I have never coded an application using an MVC design pattern and > > I''ve never built a RoR application before, I would be interested to hear > > the communities views on this. Perhaps I should be taking a slightly > > different approach. > > > > Should a background process that runs as a service leverage controllers? > > Am I leaning too much on the model for something that doesn''t have a > > user interface? > > > > - Don > > > > > > -- > > Posted via http://www.ruby-forum.com/. > > _______________________________________________ > > 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 > > >