OK, excellent. I put a first crack at goals on the planning page: http://wiki.apache.org/beehive/Planning
This is only a seed -- please update/edit at will. I'm fine if it gets rewritten. Thanks, Rich Steven Tocco wrote: >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. > >Steve > >-----Original Message----- >From: Eddie O'Neil [mailto:[EMAIL PROTECTED] >Sent: Tuesday, October 18, 2005 1:34 AM >To: Beehive Developers >Subject: Re: rails... and our v.next 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. > >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 >> >> >> >> > > > >
