Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I appreciate your desire to organize your codebase as I constantly have to convince myself not to take my default impulse to nest a resource or namespace a model. As there is no right answer to this question, I will just offer the reasons I use to convince myself not to.</p> <ul> <li>A resource lives in once place. <code>User.find(1)</code> should have a single locator (URL), which I like to call user_path. I like calling it user_path because of all the times that I have made myself call it admin_company_user_path([@company, @user]) which malaise makes in me each time I write it.</li> <li>That resource may render itself in different ways for different situations, like if the requester was an XHR or indicated that they would prefer German to English. Why is the header indicating that the user is an administrator any different?</li> <li>If I can make it look like the simplest examples in the rails/README, shouldn't I?</li> </ul> <p>At this point I would concede and end up with:</p> <pre><code>/app/controllers/companies_controller.rb /app/controllers/users_controller.rb /app/controllers/themes_controller.rb </code></pre> <p>And my routes.rb would have:</p> <pre><code>resources :users resources :companies resources :themes </code></pre> <p>I should also address how I would handle the thing that makes you want to separate them in the first place–a different view for each of the roles. In my ideal scenario, my decision would result in a <code>themes/_form.haml</code> that looks like:</p> <pre><code>= form.input :title if user_can_change_title? = form.input :theme if user_can_change_theme? </code></pre> <p>And the rest of the differences would handled in CSS, with perhaps a stylesheet for each role.</p> <p>In the less ideal scenario, I might be using:</p> <pre><code>= render :partial =&gt; "#{current_user.role}_form" </code></pre>
    singulars
    1. This table or related slice is empty.
    1. PORails Routes/Controller/Directory Structure design question
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USSam Coles
    1. USSam Coles
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PORails Routes/Controller/Directory Structure design question
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COI don't think having 3 controllers and 'ifing' my way out of it will work :( A company user cannot manage 'themes' - and setting/customizing their theme has nothing to do with theme management options that an admin has access to - it's 180 degrees different. A user profile (both for the show and edit actions) is very different if you are a user from an admin. It may as well be a different model object. There's some overlap, and some not. Admins really don't care about many things, but the 3 company user roles all care about different things. I am thinking there would 'if' hell
      singulars
      1. PO
      1. USFire Emblem
    2. COI get what you mean here, but remember the mental weight is going to exist somewhere.. either in the additional files/classes you use to separate them, or in the conditionals. With regards to a company's theme and theme management, that seems to fit natually.. only admins can `edit_theme`, whereas company users can `edit_company` which allows them to select a theme. Definitely empathetic to your aversion to "if hell" though!
      singulars
      1. PO
      1. USSam Coles
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload