WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.
Let's jump to the good stuff right away:
Okay, now let's motivate it. Let's say you're writing a migration:
Hmm, what's the second parameter to the
column method again?
Ah yes, the column type. Notice how the RDoc for the method call surrounding
the completion point is shown above - and perhaps more importantly, the symbol alternatives for
the current parameter are also
proposed below. Let's choose one.
Ah yes, the third parameter - the options. Again the documentation is
shown above (I've cropped it in this image) where you can read the details -
but many of the alternatives are listed here. Let's choose the
:null hash key.
The parameter completion support I've shown here isn't specific to ActiveRecord. Let's say you're in
an ERB file and calling into say the NumberHelpers:
Anyway, we're done editing the migration. Now let's jump over to a controller file and reference the
Product model that is using the database table for this migration. Let's ask for completion on the
@product field that was just populated with a Product object:
The icon should make it really clear that these attributes are coming from the database as opposed to some dedicated attribute code in the Product implementation. Notice how NetBeans also shows the type for each of the columns. Completion also works for the dynamic finders that Rails generates. Let's ask for completion on
find_by (this also works for
NetBeans offers code completion for models by examining the migration files. Let's go create another one. Here's
completion again, this time completing on the table name argument to
Let's say we rename the
description column to
If we now invoke code completion in the controller again, notice how the
Product attributes correctly
reflect the result of combining the migrations:
NetBeans will also use the
schema.rb file that Rails will automatically generate if you run the
db:schema:dump Rake target. This is useful if your migrations are doing creative things that NetBeans can't figure out, or if you're renaming tables (which NetBeans doesn't model right in this release.) With a schema dump file, not only does NetBeans have to do less work to figure out your migrations, its format is predictable such that the code completion should be completely accurate.
P.S. This doesn't work right if you freeze Rails into your project; you need to be using Rails via Rubygems. I'll fix that soonish.