beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Feit <richf...@gmail.com>
Subject Re: rails... and our v.next feature set
Date Wed, 19 Oct 2005 19:33:31 GMT
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:ekoneil@gmail.com] 
>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 <richfeit@gmail.com> 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
>>
>>
>>    
>>
>
>
>  
>

Mime
View raw message