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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
