My, how the tables have turned. While Colin was setting his sights on gooey
development on Sunday, I was playing with web application development.
As I mentioned earlier, I've been meaning to learn RoR, so I started this past weekend.
I'm not going to comment on the poster child of Dal CS web
development, PHP, because I'm certainly not in touch with the bleeding
edge in that area. I will, however, say some things about RoR that really
impressed me. Comparing and contrasting to language/framework X is
left as an exercise for the reader.
Cool thing #1: RoR provides scripts for creating a new
application, and for creating new models and controllers (RoR is
heavily MVC-based). So, running
give you a new directory, app_name, filled with a nice directory
hierarchy (including doc and test dirs), supporting classes, scripts, and
some basic templates which you can then fill in. Similarly,
scripts/generate model foo_model
run from the base application directory will generate a class file for the
foo_model model, and supporting test and doc files.
Cool thing #2: After your create your database tables, you never
have to write SQL again. RoR will automatically associate the
foo_model class with the foo_models table in your DB. Calling
will return an instance of foo_model with
values from the appropriate row in your DB. Additionally, RoR does the
dirty work of associating table columns with class attributes. You
never have to say that there is a foo_model.id varaible; RoR will
automagically get that from the database.
Cool thing #3: Controllers and views are dead simple, at least for prototyping during development. To associate a controller with a model, you add
to the controller class.
Then, to add views and controller actions for basic operations like add, edit, list, new, etc, you add
and that's it. no mucking about with html, or even Ruby, and you can add items, modify existing ones, delete them, via your web browser in your fancy new web app.
Cool thing #4: Composition. if a foo_model is composed of (among other things), many bar_models, then adding (in your preferred varient of SQL)
foo_model_id INTEGER NOT NULL
to the bar_model DB table,
to the foo_model class, and
to the bar_model class will create this relationship.
Then, if you have an instance of foo_model, instance_name.bar_models is a list of all the bar_models belonging to your foo_model. New bar_models can be associated with the foo_model in standard Ruby ways to access lists (list_name.push, for example), and this will automatically be updated in the database.
Needless to say, I'm pretty impressed with the Rails framework.