I’m doing very well with the Hibbs Rolling on Rails tutorial. I have an
easy question for my personal notes. I’m coming up with a simple
framework
of steps for creating a basic database. It includes the following
maxims to
make original app creation easy:
app_name = MySQL database name
SQL_tablename = model_name
model_name = controller-name
Is this going to work for getting the simple structure set up? This
naming
convention seems easy to me and should work. I’d like feedback on this
before I “make it real” for my process notes.
Second question. with this convention I’m running scaffold to get
things up
and running for testing purposes. I’ll replace the scaffold items one
at a
time until things work as expected.
when I run scaffold I’ll type “scaffold :recipes” for example. Am I
scaffolding the MySQL table when I do this or am I scaffolding the ruby
model_name?
I’m not sure but I think if you use the script/scaffolding it will
create the model and the controller at the same time… (I’m using
RadRails and it works like that)
You can also use the rails --pretend command to see if you are doing the
right thing.
Can I go with an example? I’ll show you what convention I follow.
Application name “Cookbook”.
You’d usually set up two databases on your development box:
cookbook_test
cookbook_development
One model:
ruby script/generate Recipe # generates Recipe model
The table would be called: recipes (always plural)
The controller can be called: “recipe” or “recipes”. Most people
prefer plural, i.e. “recipes”
To answer your second question: I never use scaffold, but I checked http://api.rubyonrails.com/ and you should always use the singular
name of your model, e.g.
When you enter the scaffold call into your controller (as is done in
the cookbook tutorial), you are using dynamic scaffolding that works
at run time. This will track changes in your tables.
If, instead, you run the scaffold command from the command line, this
will physically generate the scaffold code into real files and
represents the definition of your table at the time you run the
command. While this is less flexible, it does let you actually see the
code (and modify it).
Thanks for hanging in there with the new guy. One final question about
scaffolding. What I’ve been doing is placing the scaffold :model_name
in
the controller (as per Hibbs tutorial part 1) and then, when I get
everything just the way I want it I generate a scaffold command as you
have
indicated below (and as per Hibbs tutorial part 2). This allows me to
edit
the scaffold code and generally allows me an easy transition between the
dynamic scaffold and replacing and controlling each element of the
scaffold
individually.
This seems to work well and so far it has allowed me to get into
customization much more quickly than defining and controlling each def
individually.
So, I’m actually using both methods to great advantage. I " dynamically
scaffold" until I’ve got things in the order I want them in general and
then
generate a scaffold to create editable code. The generated scaffold
pulls
over (for the most part) everything as it was in the dynamic scaffold
and
saves this poor n00b a lot of headache.
The question is, is this going to bite me in the butt later on? I can’t
see
a disadvantage but I thought I’d ask the forum. I’m trying to set up a
series of “ruby habits” that will be guideposts when creating apps from
scratch.
customization much more quickly than defining and controlling each def
series of “ruby habits” that will be guideposts when creating apps from
scratch.
That’s precisely the way the I do it.
Curt
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.