Philip Hallstrom wrote:
Assume you have a web app that has users who can sign up, login and
logout, and users can seach for, and CRUD, some sort of items which get
saved in your database. Plus you have a WelcomeController that does the
main page, the "about us" links, partner sites and so on.
The question is: how do I integrate all this? For example, I need some
actions that are available globally. For every page request I need to
find out whether the user is logged in and display his account info in
the sidebar. I guess I need a :before_filter to do this, but how does
this work exactly?
In your app/controllers/application.rb, create a :before_filter that does
whatever checking you need it to do, then set say '@user' to the
logged in user, otherwise set it to nil. Now you have '@user'
available in all of your controllers and views. Personally I don't like
@user since you might have an admin that manages a @user and then you've
got conflicts. Maybe @the_end_user or @the_logged_in_user or even just
thanks for your reply! I'm guessing that using your suggested method, I can
define exceptions here, right? I.e. I don't need to check for a user if the
user calls User#login (because only anonymous users can do that) or
Welcome#about_us (because there, I don't care whether he's logged in).
How would I define exceptions? Can I say
:before_filter check_user, :except => User#login, Welcome#about_us
? AFAIUnderstand the docs, I can only specify exceptions within the same
I would also like to offer a search form on the main page without having
to resort to linking to "Search:" first.
Create app/views/shared/_search.rhtml with the search form "bucket" html
content. Then on whatever page (or in your layout) you want that on do:
<%= render :partial => 'shared/search' %>
OK, that looks simple. Thanks
I have a class "User" and a user_controller. Does logging in and out
belong into this controller or does it make sense to create another
model/controller (Login) for this?
I'd leave it in the user controller.
Makes sense. How about an admin user? I'm planning to also do
:before_filter :check_admin, only => :list, :edit, ...
Does creating a seperate "admin" controller make sense? I think not, since
the admin is just a special form of "user" (right)?
The user has_many addresses and has_many cars (for example). What's the
best way of presenting this info to the user in a way that he can most
easily edit all his info? Are there usability studies somewhere that
weigh different presentation structures?
I dunno, but I imagine there's lots of info on how to do this...
I imagine too, but most of the people who have it charge for it
I guess you need a certain expertise to make the site "feel" good.
For what should I create partials,
Whatever you might think you need to share b/n views. Or if you know you
might be updating a part of your site with ajax, make that into a partial
so it's easy to do...
Ah. Good thinking. Yes, I'm planning to add a lot of AJAX later on.
which page elements should commonly be cached,
Impossible to say without knowing your usage patterns. If nothing
changes, cache it. If it's highly dynamic, don't.
Rails includes a profiler, right? So I can see how long stuff takes.
In my old PHP app, populating a select list out of the DB, which was
displayed on the main page, took nearly 80% of the total rendering time. It
was still about 0.5s, on average, but the server load went down an order of
magnitude after I started caching that HTML snippet.
should I use link_to for all (even static) links?
Devil's advocate ... isn't that unnecessarily slower than using direct
Well, I guess I'll have to profile it ...
How do I include completely static data (does Rails realize whether a
static file with the given path exists? Does that maybe depend on the
webserver used, and the .htaccess files?)
own helper methods. Use those. Otherwise for PDF/downloads just use
link_to. For flash and embedded things, just wrap it up in the right tags
yourself (or see if there's a helper which there probably is)
"static data" as in "About us" and "Contact us" pages, terms of service and
Any pointers to documentation would be great.