Ruby web ap FUD


I haven’t stepped in here since RoR 0.6, so please
be gentle… :slight_smile:

I got the following internal email this morning; and

because I’ve only dabbled in Camping, Rails, and web aps

in general–I’m a floating-point number cruncher guy–I

thought I’d run it pass you before responding:

I’m working on archiving […] data for [a] project,

and [the Principal Investigator] mentioned using Ruby

as opposed to straight perl cgi. I am a “data modeler”

and have just branched into the perl cgi arena, due

to [staffing issues]. (Basically, they don’t have web

programmers that can do anything other than ColdFusion).

Anyway, I would like to meet with you to talk about Ruby

and it’s pros/cons in general, and possibly in relation

to the project [mentioned above].

I have heard that Ruby on Rails is only “easy” if your

data model/schema is simple, and you only present one

table’s worth of info on a form. I’ll bring a copy of

the E-R diagram to discuss, if that will help in determining

in Ruby is the right language to use for this application.

I also have the forms defined in html (used these for working

with [the PI] in determining what metadata to capture). It

looks like I would have to “redo” all the html to use Ruby


I’m also interested in the “security” aspects of using Ruby.

PHP (as opposed to ColdFusion) has been identified as having

too many security issues and therefore not encouraged here,

so I’m curious about Ruby/Ruby on Rails…

Oh, and the database is implemented in Postgres.

Thanks in advance for any light you can shed.


Bil Kleb

It's hard to imagine that anyone who sees the kind of apps -- say, Basecamp?
-- that are built with RoR could believe that Rails can't work with data
from more than one *table* per form. That particular rant aside, the
ActiveRecord pattern has been around a long while (read: it's had a while to
evolve into an extremely useful design/architectural pattern), and it has
rich support for joins and all the other SQL stuff you'd rather not write
again and again. If there's an edge case where Rails' ActiveRecord
implementation does not naturally cover the query you want, just use
find_by_sql and write SQL to your heart's desire.

There is no law that says you shouldn't have more than one kind of object
per form or page. Master/detail forms often do this. Perhaps I misunderstood
the comment.

Regarding the HTML, Rails does essentially the same thing ASP.Net,
PHP/Smarty and a number of other frameworks do: It uses a decorated HTML
template that contains a certain amount of code. In Rails' case, it RHTML.
Will you have to redo your HTML completely? No. Will you want to redo it
some? Probably. Rails provides form helpers that afford a good deal of
consistency and predictability that raw HTML coding might not. By the way,
you'd be faced with the same hurdle with any templating language. As an
aside, why are you writing HTML prior to choosing a platform?

Finally, regarding security, the biggest security risk I know of is at the
application design level. There is no hack-proof platform, but most
successful ones are relatively mindful of security. As the application
architect, it's up to you to specify your security requirements and devise a
plan that proves that you have met those requirements. The beauty of open
source is that should you encounter a hole, you can plug it. Pronto.


Bil Kleb-2 wrote: