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. Eddie On 10/18/05, Rich Feit <[EMAIL PROTECTED]> 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 > (http://www.theserverside.com/news/thread.tss?thread_id=37121 ). 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 > >
