I haven’t stepped in here since RoR 0.6, so please
be gentle…
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
methods?
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…
I have heard that Ruby on Rails is only “easy” if your
data model/schema is simple,
We have 83 tables in our application, fully normalized, with a few
de-normalized views. It is a very complex data model. It was based on an
existing data model, so many of the tables have non-integer,
non-autonumbering primary key columns, and we also have many join tables
with composite primary keys made up of the parent foreign keys. BTW, we
did have to write about 8 lines of custom code (in a plugin) to get the
non-integer, non-autonumbering PKs to work with ActiveRecord’s existing
methods.
and you only present one
table’s worth of info on a form.
Not true, you can display as much or little information on a form as you
want. We have several forms that display and allow entry of data from 6
or more tables. With transactions, we can update all or none, and we
correctly display error messages for each field.
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
methods?
Well, the best way would probably be to edit the HTML forms to insert
embedded Ruby code to handle the dynamic aspects of the forms. This
would convert them to ‘RHTML’ forms, the standard way of writing Ruby
forms. If it was very important to keep fully HTML forms, you can use
other templating languages (like Cerise I think?) that use plain HTML
and then substitute various DOM elements to put dynamic content in.
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…
No issues so far for us.
Oh, and the database is implemented in Postgres.
We’re running Postgres 8.1.4
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.
