I was trying to work out how to do logins - I read on one tutorial that logins would be run through a sessions controller with new, create and destroy actions. This makes some sense to me - obviously destroy is for logging out and create is the action of logging in (and I assume new is the log in form?
Yep, you've got it. The login/logout actions happen to fit well with the RESTful idea (login as create session and logout as destroy session). But, some people think this is going a little too far into REST and that is perfectly okay too. You are free to use a non-RESTful controller for the login/logout actions if you want.
As for learning the REST design, I don't think login/logout is the best/simplest example.
I'm not completely sure of the distinction between new and create).
The "new" action is for displaying the form for someone to input the data, the "create" action accepts the data inserted into the form, puts it into a model, and saves it. The two are similar, but the distinction is important. Same goes with the edit/update actions.
What about seeing if someone is logged in - would this just be done with the view and session parameters?
Every controller needs to see who is logged in, so this logic shouldn't just go in the SessionsController. A better place is the ApplicationController so every controller inherits the behavior. I usually use a method similar to this:
@current_user ||= User.find_by_id(session[:user_id])
This way any controller can just call "current_user".
I'm not sure whether or not REST is going to work for me. My site is split at the top level into "themes", each theme has a number of "tasks" and each task has a variety of objects - documents, tips, contacts, links. You only view a tip/contact/link within a task although they are stored in separate models (while a document will have a page of it's own). So a task page will show all tips, contacts, links and documents on the page. I'm not sure how this will work with REST. How do I specify that /themes/1/tasks/2/ displays all these different things? It may be just that I'm overcomplicating matters or not fully understanding REST. I'm still very new to Rails so I'm wondering if trying REST too is just a bit in over my head. But then I'd prefer to do things and learn things the RESTful way from the start.
It sounds like this will work well with REST. First you create a controller for each resource/model you need an interface for. I recommend starting at the top. So, you would first create a Themes controller with basic CRUD operations (create, read, update, destroy). The controller doesn't need to perform all of these actions, just whatever the application requires. Then create a Tasks controller the same way.
This may be all you need since you are displaying the documents in the task's show page. But, do you need some way create/update/destroy these other models? Most likely so. This calls for another controller for each model. You don't need to have the list/show actions in the other controllers since you just need the create/update/destroy functionality.
Hopefully I cleared some things up and didn't confuse you more.
- Free Ruby on Rails Screencasts