Where to put code - controller or model

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)?

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.

On 7/6/06, Roland M. [email protected] 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 V.

On 06/07/06, Chuck V. [email protected] 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 7/6/06, Chuck V. [email protected] 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.

On 07/07/2006, at 2:45 AM, Chuck V. 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

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.

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 V.

On 07/07/2006, at 2:45 AM, Chuck V. 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 Y.
http://9cays.com/

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs