Rails - Jul 2006 - 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)?

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

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/

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