struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mart...@apache.org>
Subject Re: [Proposal] Struts Ti
Date Thu, 04 Aug 2005 03:33:32 GMT
This looks really good, and fits well with my belief that the way to get 
to Struts 2.0 is to start by building a new core first, and then adding a 
compatibility layer on top of that to help people migrate.

>From my own perspective, it shouldn't be a surprise to most on this list 
that I have a particular interest in facilitating the creation of rich web 
applications - applications which may be component based, but not server 
side components. This proposal sets out on the right path towards that 
goal, and I'm planning on furthering that.

One other aspect that Don didn't mention explicitly (but which I know he 
had in mind) is designing for testability. Right from the get-go, we need 
to build in tests wherever we can.

We've learned a lot from Struts' evolution, and we can and should learn 
from how other projects have tackled some of the same problems. Also, as 
Don said, it's time we started collaborating more closely with some of 
these other projects, so that we can pool our resources rather than 
duplicate effort.

--
Martin Cooper


On Tue, 2 Aug 2005, Don Brown wrote:

> I'd been waiting to announce/propose this until I could write up a decent 
> proposal and have the code in a better state, but with all the talk about 
> Struts 2.0, "good" now is better than "better" tomorrow I suppose.  The 
> following is a proposal for Struts Ti, a possible successor to Struts 
> classic:
>
> Struts Ti is a simplified Model 2 framework for developing webapps which 
> allows the developer better access to the underlying servlet/portlet 
> environment. It serves a niche of web applications that don?t want the 
> additional complexity of server-side components and verbose configuration, 
> yet want the structure and controller features of a modern web framework. 
> Struts Ti builds on the directions of Struts 1.x, yet re-implements the 
> framework to provide a clean slate for the next generation of Struts Ti. It 
> aims to combine the simplicity of Ruby on Rails and NanoWeb, the refinement 
> of WebWork 2, the tool-friendly authoring and Page Flow of Beehive, and the 
> lessons learned from Struts 1.x.
>
> The key word for Struts Ti is simplicity. Ideally, Struts Ti should approach 
> Ruby on Rails levels of easy of use, yet scale up to large applications 
> providing a smooth transition to JSF/Shale if desired.
>
> Key Features
>
>    * POJO-based action that combines an Action and ActionForm in a similar 
> manner to JSF backing beans and WebWork 2 Commands
>    * Intelligent defaults utilizing naming and placement conventions to 
> require minimal, if any, configuration per page, however it will be possible 
> to override everything on a global and per-action basis
>    * Configuration can be ?assumed? or declared through annotations, xml or 
> properties files, or any other pluggable mechanism
>    * Pluggable EL for data binding defaulting to JSP 2.0 EL but allowing 
> OGNL or even BeanUtils
>    * Integration of a dialog or page flow capability drawing from Beehive, 
> Spring?s web flow, and Shale?s Dialogs.
>    * Per-Action optional interceptor chain ala WebWork 2
>    * Built-in dependency injection support
>
> Design Goals
>
>    * No servlet dependency in core framework, portlet and JSF support out of 
> the box
>    * Spring-based dependency injection in core to allow for pluggability
>    * No bias to any view technology
>    * Ability to layer Struts 1.x compatibility on top
>    * Highly toolable
>    * Smooth integration into a portal/portlet environment
>    * AJAX-friendly
>
> Implementation
>
>    * Built on the backbone of commons-chain
>    * No restriction on multiple Servlets and/or Servlet Filter 
> implementations
>    * Key decision points (action selection for example) use CoR chain for 
> maximum flexiblity
>    * Configuration specified using XDoclet (Java 1.4) or Annotations (Java 
> 5+), both supported out of the box
>
> Dependencies
>
>    * Servlets 2.4
>    * Java 1.4 runtime, Java 1.5 to build
>    * JSP 2.0 if taglibs used
>
> Existing project collaboration
>
>    * XWork/WebWork using their XWork and possibly parts/all of their tag 
> libraries
>    * Beehive using the Page Flow and annotations
>
> Status
>
> I've setup a project site for myself and have a working, if feature sparce, 
> framework in place.  In feeling out the scope of the project, I've been 
> working with the two projects above as I want to avoid reimplementing 
> anything I don't have to, and think there is a lot of synergy to be had.
>
> At this point, the project site, code, and more detailed design discussions 
> are on my personal server:
>
> https://www.twdata.org/projects/struts-ti
>
> However, I plan to move everything over to the sandbox to start the 
> incubation process and await acceptance by the Struts PMC and developer 
> community.  I've stated before and I'm sure I'll be stating again, and again, 
> Struts Ti does NOT compete with Struts Shale, as I see them, if accepted, as 
> two sibiling projects serving different niches.
>
> I've been watching the Struts 2.0 threads with interest and hope this 
> proposal meets the needs of the Struts community for a successor to Struts 
> Classic.
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message