Newb question

I already have AWDWR and have done a number of tutorials , so it’s okay
to
refer me to those however I’d prefer, if there is a semi-simple answer
to
this to perhaps offer one up.

I want to build a site that will work around “role based” authentication
and
I’m thinking about it in relation to my directory structure.
so the roles might be:
company
group
user-gold
user-silver

would I build a directory structure like:
company/index
company/do_something
company/do_something_else

group/index
group/do_something
group/do_something_else …

usergold/index
usergold/do_something
… and on

if this makes sense , do I then make controllers for each page ? i.e:
generate controller company index
generate controller company do_something_else
generate controller usergold do_something

Or am I totally missing something here ?
Hope I made the question clear enough.
Appreciate any explanation
TIA
Stuart

If you haven’t already, watch the blog demo video:
http://media.rubyonrails.org/video/rails_take2_with_sound.mov

Is a great tutorial that may help you understand
controllers/directories.

Your controller names will show up in your URLs, so you should pick
controller names that make sense like: login (holds all your login
login), users (holds your user logic), groups (etc etc).

On 12/07/06, David C. [email protected] wrote:

Your controller names will show up in your URLs, so you should pick
controller names that make sense like: login (holds all your login
login), users (holds your user logic), groups (etc etc).

No, your controller names will show up in your URLs by default. This
can, of course, be changed in routes.rb.

As regards structuring your app: I don’t think you need a seperate
controller for each level of access. You might want to seperate out
(say) an administrative/corporate backend from a user-facing front
end, though.

To give you an example based on what you’ve given us: why do you need
a user-gold controller and a user-silver controller? Why not just have
a user controller, store the user’s access level in a cookie/session,
and then display content conditionally dependent on their status?

Using a controller for each access level will lead to lots of
repetition. In this case, that’s a bad thing.

On 7/12/06, Tom A. [email protected] wrote:

To give you an example based on what you’ve given us: why do you need
a user-gold controller and a user-silver controller? Why not just have
a user controller, store the user’s access level in a cookie/session,
and then display content conditionally dependent on their status?

Probably don’t need seperate ones. I’ll narrow it down for the moment so
perhaps my confusion can be cleared up:
so usergold after logging in goes to
usergold/index (from there there are links and perhaps some of their
account
information)
the links might be
usergold/searcharticles
usergold/postarticles
usergold/checkforum
usergold/upgrade

I guess, the way it works is all the code is in the usergold controller
and
then each function has it’s methods and within those functions
information
about the correct view to pull up ?

Stuart

so usergold after logging in goes to
usergold/index (from there there are links and perhaps some of their
account information)
the links might be
usergold/searcharticles
usergold/postarticles
usergold/checkforum
usergold/upgrade

This is really not a cool idea IMO. What Tom suggested is the way to
go. Create your controllers to handle the content and protect using
filters. Your controllers should look something like:

user/
articles/search/
articles/post/
forums/1/
memberships/upgrade/

Steve

I guess, the way it works is all the code is in the usergold controller and
then each function has it’s methods and within those functions information
about the correct view to pull up ?

Maybe. Let’s get the terminology right, though, for clarity:

if there’s some conditional data, you might want to put some
conditional statements into each action in the controller so that only
the necessary data is passed to the view. You could then put
conditional statements in the view to show extra stuff for certain
classes of users.

Alternatively, if there are some pages that only a “gold” user might
see, then it might be worth making seperate views for those, and then
putting the call to render that view in a conditional statement on the
controller. Does that make sense?

On 7/12/06, Tom A. [email protected] wrote:

the necessary data is passed to the view. You could then put
conditional statements in the view to show extra stuff for certain
classes of users.

Okay I understand that and have done that similarly in PHP (not to
dredge up
that beast :))
As well, blocked entire pages based on the access level of the user.

Alternatively, if there are some pages that only a “gold” user might

see, then it might be worth making seperate views for those, and then
putting the call to render that view in a conditional statement on the
controller. Does that make sense?

Yes, it makes sense. Unfortunately I am still stuck back at part of my
original question, but will ask it again in a revised form in light of
these
clarificaitons -
Should I just forget about the idea of “directories” when designing in
ROR
?

Stuart

Thanks Dan, just got done reading about routing and also the section in
AWDWR. I see the point though in coming back after the controllers are
set
up.

Stuart

Create your controllers based on the actions that users will be
doing. Then, separately, construct your urls using routes to have
the “directories” look however you want them to.

e.g.: map.connect ‘:year/:month/:day’, :controller =>
‘blog’, :action => ‘by_date’

For a simple app, you should easily be able to have a number of
controllers, each with a number of actions, without needing any more
hierarchy in your controller directory. What you expose to users is
entirely independent.

http://manuals.rubyonrails.com/read/chapter/65

New question: what happened to the API docs for
ActionController::Routing?
http://api.rubyonrails.com/

        - dan


Dan K. mailto:[email protected]
http://www.dankohn.com/ tel:+1-415-233-1000

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