Topic: It works, but is it 'Railsesque'?

I have a data model where a user has one and only one profile, and each profile belongs to one and only one user.  I've established this as follows:

class User < ActiveRecord::Base
  has_one :profile
  ...

class Profile < ActiveRecord::Base
  belongs_to :user
end

Now, I want the user to be able to view his or her very own profile.  So in my profile_controller.rb file I have:

class ProfileController < ApplicationController
  scaffold :profile
  def list
      @profile = Profile.find_by_user_id(@session[:user].id)
  end
end

And my list.rhtml view is just:
<table>
    <tr>
       <td><%= @profile.suburb %></td>
      </tr>
</table>

Now, this works.  After logging in, the user browses to /profile/list, and the profile is listed (well, the suburb is). 

However I'm wondering ... is the list action really an appropriate name if there's ever going to be one profile?  I'm not sure that the view action is appropriate though, as that's for viewing a particular record, and there's only ever going to be the one of them per user.

Any help would be greatly appreciated ... I don't just want my app to work, I want it to be conventional, both for my peace of mind and for added value for my client.

Re: It works, but is it 'Railsesque'?

Show.  The action name is show.  Jebus.  Must be time for a can of cola ...

Re: It works, but is it 'Railsesque'?

Hmmm ... on a related note - is it acceptable to have 'show' default to the id of the user's profile?  I.e. have profile_controller.rb do something like:

def show
  # if we don't have an id specified, use the default profile for the user
  if ! @params[:id]
    @profile = Profile.find_by_user_id(@session[:user][:id])
  else
    @profile = Profile.find(@params[:id])
  end
end

Also, every user must have a profile.  Currently I'm planning on creating a new one when the user is created, in user_controller.rb.  Does that make sense, or is there a Railsesque place to be doing that kind of data creation?

Re: It works, but is it 'Railsesque'?

@params is deprecated, use params instead (ie, just drop off the ampersand)

The rails scaffolding just creates a very generic CRUD based user interface. It's not expected your application will fall into the scaffold's interface. If it did we'd all just use the scaffolding and be done with it. So name your actions as appropriate to your application.

Here is how I would do it:

class ProfileController < ApplicationController
   def show
      @profile = Profile.find(params[:id])
   end
end

I'd call it 'show' since that is what you are doing, showing a profile. I think 'view' would work just as well. No need to call it 'show_profile' because it's the profile controller, it's obvious we are showing profiles.

I have completely decoupled the ProfileController from any notion of a User or session. the ProfileController only knows about Profiles and how to invoke views to display/edit/etc them. By having each piece of your application know as little as possible about other pieces, your app becomes more flexible, more easily changed for future needs, and more modular.

What if the current logged in user wanted to see someone else's profile? With your code, you can't really. With mine, I can just pass in their id to the show action, no change needed.

I also wouldn't have the ProfileController dig into the session unless his actions are session oriented. If the profile could care less where or how or why this profile is being shown, then just keep it stateless. Stateless is almost certainly less buggy than stateful smile

That's just my opinion, others may disagree.

Re: It works, but is it 'Railsesque'?

duncan_bayne wrote:

Also, every user must have a profile.  Currently I'm planning on creating a new one when the user is created, in user_controller.rb.  Does that make sense, or is there a Railsesque place to be doing that kind of data creation?

Again, just my opinion, but I'd do that as a before_create in the User model

class User < ActiveRecord::Base

   def before_create
       self.profile = Profile.new
   end
end


"before_create" is a callback method. from the documentation: "before_create Is called before Base.save on new objects that haven