beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie O'Neil <>
Subject Re: rails... and our feature set
Date Tue, 18 Oct 2005 07:34:09 GMT
  Yeah, I'm a big fan of building this functionality into Beehive; the
project is well suited to support pattern and metadata driven
application development.

  Personally, I think that this should be a big part of our mission
statement for ongoing work, and I'd be thrilled to work on it.


On 10/18/05, Rich Feit <> wrote:
> Bruce Tate, a (former?) Java evangelist, became an advocate for Ruby on
> Rails and caused a large, passionate thread on TSS about RoR vs. Java
> ( ).  Of all
> the posts, I was struck by one of Bruce's that describes why RoR is
> different:
> > .... For at least one class of applications, web-based apps on a
> > relational database where you control your own schema, you'd be crazy
> > not to consider Rails. It's just too productive. I didn't understand
> > either until I used the framework in anger. What's different?
> >
> > - Rapid turnaround time. Save and reload. That's it. Very compelling.
> >
> > - Starting point. You start with basically a working CRUD app per
> > table. Windows to do list, show, edit, delete, new. Sure, you'll
> > rewrite some, but you can put something in front of your customer
> > instantly. That's compelling. To get all of this, you can either do a
> > one-time code generation pass (it's not that much code in Rails), or
> > you can do a scaffold :person command.
> >
> > - Reduced configuration. For us it was a 10-1 reduction. I think
> > that's fairly typical. More for some extreme struts apps, less if you
> > don't count annotations (but I think we're often making a big mistake
> > with annotations.)
> >
> > - Better mapping strategy for the Rails problem set. Here's an active
> > record class, that maps a Person class to a table called people, and
> > belongs to a department:
> >
> > class Person < ActiveRecord::Base
> >   belongs_to :department
> > end
> >
> > End of story. You want syntax? That's syntax. You get a property for
> > every column in the database, custom finders like find_by_last_name,
> > and other goodies to manage the belongs_to relationship. No repetition
> > of column names. No code generation.
> >
> > - Much better AJAX, and cleaner view technology.
> > As to quick and dirty, I used Java because it was clean, although
> > slow. I didn't use PHP or Perl because I think they are quick and
> > dirty. I think Ruby on Rails is quick and clean.
> The interesting thing is that a lot of this stuff could easily be
> supported in Java web frameworks, and Beehive in particular is
> well-suited (e.g., with its single-annotated-file model).
> DISCLAIMER: I am *not* the first person to make the statement above...
> in fact, I think I've heard basically the exact same thing from Daryl.
> I'm just being struck by it.  But... is this something that can help us
> define a mission statement for the next set of Beehive features?  We
> don't need to *be* Rails, but we could certainly learn from it.
> Rich

View raw message