beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Feit <>
Subject Re: Beehive/Spring/Struts/WebWork
Date Tue, 11 Oct 2005 15:19:13 GMT
Thanks for the response, Daryl.

I think the Clarity folks realized that they were biting off more than
they could chew, so they reduced the scope.  Clarity will first focus at
the level of Struts/WebWork/Spring  MVC, without something like Page
Flow.  The Beehive community can remain an observer for now (assuming we
don't want to try and contribute our tags as their view layer :) ).


Daryl Olander wrote:

>Hoping to kick off a bit of a discussion here, I'll start from the stated
>"rules", though these seem to be a bit of both rules and goals....
>I'm not sure that I see a lot of need for consolidation in this market. It
>seems to me like Beehive NetUI has hit a sweet spot. We are already
>integrated directly with struts and provide a bunch of V2 Web Framework
>support such as meta data, automatic state management, and nesting; too name
>a few. In addition, we support multiple view technologies and have good
>integration with JSF. I've haven't seen Beehive users demand for integration
>or support of either Spring WebFlow or WebWork. They have asked for AJAX,
>structs migration, etc.
>In addition, I'm not sure what means to consolidate these frameworks. Does
>it mean that the Struts XML configuration file, SWF Flow Definition and an
>annotated page flow all continue to exist? Or do we take the "ideas"
>embodied in these projects (actions, flow, etc) and move them into a new
>light weight framework and simply provide a migration from existing
>projects? In today's model for NetUI, we have almost a duel Meta data model
>at the implementation level (struts config files and annotations in the page
>flow), but a single programming model (annotations). In a consolidated world
>are we consolidating at the programming model, configuration and/or API
>There are a number of other frameworks that are stacking out territory in
>this world (JSF/myFaces, Shale, and Seam), should we consider bringing them
>in? There are bunches of smaller frameworks that certainly have interesting
>properties (Tapestry) or large number of users (velocity). These aren't
>represented here either. Consolidation is an interesting goal, but why
>choose some and not others?
>Overall it seems to me, that being at the "top" of the stack, having a
>number of choices is good for users. There is less technical reason for
>consolidation at this level. You can pick your framework based upon the
>features, standards, the programming model, and the tools.
>Second, I'm very uncomfortable about this:
>- *All project leaders understand that once this project is releases, future
>work their own projects should cease (other than supporting it, minor
>releases, migration path to Clarity, etc).*
>I think we cut off adoption of Beehive if we commit to any project that
>promises to end-of-life NetUI in the next year or two. Why adopt Beehive (or
>SWF) if you know that a year from now, you'll be adopting a new framework? If
>this is your current choice, I think you'd be better off looking hard at
>Shale and Seam or just continuing to use Struts and see where the dust
>settles. Don't we owe our current and future users our ear to listen to
>their requirements, criticism and suggestions and implement them to the best
>of our ability within our framework? Our commitment is to move them forward
>as the web and technology evolve (AJAX, Web 2.0, EJB 3.0, etc)
>Overall, I feel like Beehive would be better off moving forward. We just
>shipped 1.0 and we have a pile of features we can do, many of which compete
>directly against Shale, ASP.NET <http://ASP.NET>, RubyOnRails and Seam. If
>we spent a year developing some of those features we are further along than
>if we spend a year figuring out how to coexist with a couple of other
>existing frameworks.
>On 10/10/05, Daryl Olander <> wrote:
>>Pulling from the mail below to summerize (emphasis is mine):
>>From: Patrick Lightbody <>
>>To: Rich Feit <>
>>Date: Thu, 6 Oct 2005 08:20:02 -0700
>>Subject: Re: Project Clarity Kickoff
>>So here are my ideal set of rules. Please adjust as you see fit:
>>- Above all else, we recognize that consolidation is the overriding goal.
>>- We recognize that we'll all have to compromise on items we are
>>passionate about, but that the overall project success is more important.
>>- This project aims to unify WebWork, Struts, Spring MVC, Beehive, and
>>Spring WebFlow in to a single project that establishes clear leadership in
>>the web development space.
>>- All project leaders understand that once this project is releases,
>>future work their own projects should cease (other than supporting it, minor
>>releases, migration path to Clarity, etc).
>>- Technical disputes should be coordinated by those _least_ familiar with
>>the topic, and therefore least biased.
>>- When criticizing or proposing alternatives or otherwise "stopping
>>forward progress" - we promise to ask ourselves if this issue we're about to
>>raise is really "worth it".
>>- We recognize that not everyone works the way we do and we understand
>>that we may have to work hard to find common ground.

View raw message