beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Tocco" <>
Subject RE: rails... and our feature set
Date Tue, 18 Oct 2005 14:57:27 GMT
Seems like a good thing to me as well.  

I think it might help beehive adoption and utility as the tooling sector
tries to catch up.


-----Original Message-----
From: Eddie O'Neil [] 
Sent: Tuesday, October 18, 2005 1:34 AM
To: Beehive Developers
Subject: Re: rails... and our feature set

  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
> Rails and caused a large, passionate thread on TSS about RoR vs. Java
> ( ).  Of
> 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
> > 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
> >
> > - 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
> > 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
> > don't count annotations (but I think we're often making a big
> > with annotations.)
> >
> > - Better mapping strategy for the Rails problem set. Here's an
> > 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
> > 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
> 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