Jewels and Stones
So my web design opportunities have slimmed down. That’s to be expected, really. I had two people courting me for help, only one has come through with plans, meetings, and a set of requirements. So, naturally, that is the one I will work on.
I’ve already made a temporary site; it’s mostly in Perl and straight HTML. Got a webmail form, a hard-coded gallery, and a front page set up. The site is mostly served from cgi scripts using templates; each script is specialized to its own page. Boy, do I love Template Toolkit.
After some careful thought, investigation, and simple tests, I decided that Maypole, the Perl Model-View-Controller application framework, though it’s powerful in its own right, had some shortcomings. In one review of Maypole I read, the writer stated that he had a difficult time setting up Maypole to do anything beyond the sample demo applications that are provided in the documentation. I tend to agree with that writer. It’s got promise, but there’s some gnarly details that need to be hammered out before I can do something large-scale with it.
All this talk I’ve made about Maypole being the Perl equivalent of Ruby On Rails, I decided, in one evening of frustration, to actually look into Rails. After reading some docs, installing Ruby, Gem, and Rails, and building some demo applications, I’m kind of sold on the idea. A simple application can be built in one night, a medium one in a few, and a complex one in a few weeks…given I can focus on the task.
Ruby is a strange and foreign language to me, given my history with Perl and Javascript. Everything is an object, like in Javascript, and everything returns something, like in Perl. In Ruby’s case, everything, from constants, to strings, integers, floats, and on up are a subclass of Object, and as such feature a few built-in methods. What most people call methods, Ruby calls messages. You have an object of a certain class, and it has methods that are called with messages like so: someObject.sayHello("Hi There") This is similar in structure to Javascript’s heavy usage of dot notation, but I think the depth stops at one dot. Ruby also has little need of the semicolon to punctuate statements; this I find alien and a little offsetting. They’re really only needed for multiple statements on one line, otherwise the newlines delineate statements.
Perhaps one of Ruby’s greatest strengths, one I’m barely understanding, is its ability to encapsulate blocks of code and store them, and their variables, into persistent chunks to be thrown around as closures, iterators, etcetera. This is where curly braces are most likely to be found. Ruby doesn’t require curly braces around methods, loops, conditions, or anywhere else; those are enclosed by the statement itself and its corresponding end statement.
Rails is programmed in Ruby, and it takes advantage of Ruby’s strengths. Most important to Rails is the class ActiveRecord, which is Ruby’s version of Perl’s venerable Class::DBI module; each object of that class corresponds in some way to a specific record in a specific database table. Coupled with that is a menagerie of other Rails classes such as ActionController and ActionView which round out the triumvirate of the Model-View-Controller paradigm.
Rails is much like Maypole in that it takes only a few real lines of programmer code to make it work. When one creates a Rails application on the command line, Rails builds a generic framework of directories, templates, scripts, tests, and configuration files you can then edit. Once you configure the application to use the database, and have created your tables, you can then ask Rails to create for you a scaffold of classes, templates, and controller methods so you can start manipulating records in the database right off the bat. Once you are done with the generic “CRUD” methods (Create, Retrieve, Update, Delete), you can then replace them with your own custom methods.
As good as all this sounds, what makes me balk about the framework is that, to the uninitiated, Ruby On Rails has some damnable voodoo in it. By this I mean that there are requirements to the way you name your database tables, the fields in those tables, and your application classes; you must conform to certain naming conventions for Rails to automatically see and interact with them, elsewise you’re scratching your head trying to find a way to force Rails to see things your way (which there are ways).
One such naming convention is that your tables must be a plural of what they hold; for instance, you have a table where each record is a “toy”, therefore the table must be named “toys”. Rails has singular-to-plural inflection code built in. Your model must be named “toys”, your application controller class, “toys”, your templates will be in the “toys” directory. Some damnable voodoo indeed! I’ve yet to discover where I can expect Rails to do this, but there are ways to circumvent it, fear not. Most of Rails’ personality is configurable, but doing so makes so much of the automatic things that Rails does fewer and farther between.
So this website I’m building; it’s turning into this smallfry e-commerce storefront with multiple vendors, multiple products, pictures, a blog, a webmail system, back-office report generation, and so on. It gives me trepidation to think what all I have before me. I know I’m not going to get any barebones functionality ready before deadline, but it’s my hope that my client will understand and will be lenient on me. Learning a new language, discovering the powers and caveats of a new framework, trying to handle the things in my personal life…it’s a lot of work.
