beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Feit <richf...@gmail.com>
Subject Re: Beehive/Spring/Struts/WebWork
Date Tue, 11 Oct 2005 15:44:30 GMT
No.  It means they're reducing scope in order to be able to move
forward.  SWF isn't in this either, and the group expressed the hope
that SWF and Beehive will work together in parallel.

Rich

Daryl Olander wrote:

>So they've rejected Page Flow as the 'C' layer here? Page flow is all about
>the controller layer. Does this mean that SWF is the exposed controller?
>
>On 10/11/05, Rich Feit <richfeit@gmail.com> wrote:
>  
>
>>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 :) ).
>>
>>Rich
>>
>>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
>>>level?
>>>
>>>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> <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 <dolander@gmail.com> wrote:
>>>
>>>
>>>      
>>>
>>>>Pulling from the mail below to summerize (emphasis is mine):
>>>>
>>>>From: Patrick Lightbody <plightbo@gmail.com>
>>>>To: Rich Feit <richfeit@gmail.com>
>>>>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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>
>  
>

Mime
View raw message