Beginners confusion

Hi,

Sorry if this is stupid questions.

I’m new to Ruby on Rails. I’ve watched and read a couple of tutorials
and think I get a decent grip on how things work.

Some stuff puzzles me though:

  1. All the tutorials show who you do things in subdirectorys (for
    example: localhost/myproject/blog). How do I do to get things to
    happend in the root of my project?

  2. What are the difference between the directories \app\views and
    \public , how do you use them in conjunction with each other?

  3. How do you separate the frontend from the backend? Let’s say that
    you have a blog with posts and comments. Then you want yourself to be
    able to CURD both posts and comments and everyone else just be able to
    add comments.

What I’ve seen of Rails seams great but it’s sort of hard to let go of
all the control you felt like you had when doing everything by hand. On
the other hand is so sweet that things just happend (you know what i
mean).

Thanks in advance!

Also sorry for bad english.

Alfred

Alfred,

I very strongly suggest that you grab a copy of the 2nd Edition of Agile
Web
Development with Rails from the Pragmatic Programmers website. Right
now
it’s only available as a PDF. It should answer your questions.

I’m not really sure what you’re asking in question 1. For question 2,
you
need to learn about the routes.rb file that’s in the config directory.
It
determines where to route calls to your views, etc based on the incoming
URL. Your public directory is still the “face” of your app, but
routes.rbdetermines where to go.

If you look at routes.rb, there’s a commented line that looks like this:

map.connect ‘’, :controller => “welcome”

If you uncomment it, and type in the name of one of your controllers,
then,
if you create a view for that controller and name it index.rhtml, when
someone visits your app, like at yourappdomain.com, then they will be
routed
to the index.rhtml file for that controller. You do have to remove the
default index.rhtml file that’s in your public directory.

The book I mentioned goes into much deeper detail.

As for question 3, the controllers and associated help files and library
files, etc form your back-end. All of that code runs on the server -
not in
your browser. Place your non-UI related logic down into your server
code
(controllers, etc).

I hope that helps a little bit, or at least gets you started. Again,
please
get the Agile Web Dev book! It’s well worth the price!

On 9/26/06, prtscr [email protected] wrote:

add comments.
Alfred


Terry (TAD) Donaghe
http://www.tadspot.com
http://www.rubynoob.com

First off, I’m going to second Terry’s recommendation that you work
through a full book on rails. While the beginner tutorials are great for
giving you an overview of a particular task, you’re not going to get a
firm grasp of the big picture in rails just from tutorials. A book will
fill in a lot of the gaps for you.

prtscr wrote:

  1. All the tutorials show who you do things in subdirectorys (for
    example: localhost/myproject/blog). How do I do to get things to
    happend in the root of my project?

This is called routing. The root of your project is called the default
route. Take a look in config/routes.rb, and in particular, at the line
which includes

map.connect '', [...]

This is where you would specify what you want your default controller
(and action) to be. There are a number of good reference to routing
online, if you google for it.

  1. What are the difference between the directories \app\views and
    \public , how do you use them in conjunction with each other?

your public directory stores all of the static files used by your
railsapp. This includes your images, stylesheets, javascripts, and so
forth. That “Welcome aboard” page you get when you first load rails?
That’s also a static file – index.html. These are all things which the
web server can hand off directly, without having to broker them through
ruby.

your app/views are rails template files. These provide the “view” or
layout of the pages which rails generates.

  1. How do you separate the frontend from the backend? Let’s say that
    you have a blog with posts and comments. Then you want yourself to be
    able to CURD both posts and comments and everyone else just be able to
    add comments.

Instead of thinking of this as “frontend” versus “backend”, think of it
as access controls. You have visitors who access your site. You want to
some of those visitors to have access or permission to certain actions
on your site.

First you need a way of determing who a visitor is (“authentication”).
This is usually done through some sort of login widget. If you google
for “rails +login” or “rails +authentication” you’ll find a number of
options, including tutorials on how to write your own.

Second, you need to decide on what roles you want to have. This could be
as simple as “admin” and everyone else.

You need a way to assign those roles to user. If your needs are very
simple, you could update your users model to include a “role” column.
Alternatively, you could have a separate “roles” model and then a join
table which assigns roles to users.

Third, you need to restrict or grant access to your controllers/actions
based on the role of the current user. This could be done through a
before_filter which checks current_user.role before it loads the
requested controller/action. If the check fails, then the user will be
redirected elsewhere.

This sort of thing is covered in the “Rails Recipes” pdf from the
Pragmatic Programmers website. You will also find a number of tutorials
and plugins which will show you different ways of accomplishing it. This
can get to be a fairly complicated topic, and is well worth reading up
on :wink:

I hope that helps get you started!

~gwendy

Thanks a lot! This i very exiting.

I’m not used to the controller/model/view approach at all but now I got
a better image of it.

The access control way of thinking sounds really obvious when you say
it. :wink:

And I will buy the Agile Web D. with Rails PDF.

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