I'm kind of surprised with all the replies indicating the willingness to
think much more revolutionary rather than evolutionary... I can't say I
expected that, but I'm really quite happy about being wrong :)
I really think web applications to this point, on the whole, have been
rather lousy. I'm not saying anything new when I say that web-based
applications set interface design back at least five years. We're only
now starting to recover from that bit.
With that thought in mind, I personally see the next evolution almost
really being two frameworks that work in tandem... and maybe even it is
*literally* that... one the usual server-side framework, but now with a
client-side component that is a fair ways beyond anything we have today.
They have to be intimately tied together to really make it worth it,
but I see them both being fairly complex endeavors.
We're seeing a lot of experimentation in that direction... ASP.Net, JSF,
all the various Java frameworks out there, more open-source projects
than you can count... but I'm not sure any of them are quite "right"
yet. So, when Martin says "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", I couldn't agree more... I think the next evolution
of Struts will most definitely be a fusion of a lot of the ideas we're
playing with today, and more that we haven't yet thought of.
Exciting times for sure :)
Frank
Martin Cooper wrote:
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]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
