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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > >>Pulling from the mail below to summerize (emphasis is mine): > >> > >>From: Patrick Lightbody <[EMAIL PROTECTED]> > >>To: Rich Feit <[EMAIL PROTECTED]> > >>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. > >> > >> > >> > >> > >> > > > > > > >
