I'm wondering how you can satisfy both "Soup to nuts" and "Less is more"
with one solution ... or are these multiple visions for multiple
solutions?
For the record, I am not in favour of turning Struts into a "stack"
solution. In my opinion, one of the strengths of Struts 1 was that we
provided only the core web framework, and didn't make decisions for web
developers as to which solution they should choose for persistence,
etc. We
were always very consious that if we were to choose one, it would be
seen to
be favoured above others, when that was not our intent. That being the
case,
it was clear that our users could select whatever best matched their
application.
And that last part - selecting the best match - brings me to the other
reason that I don't want to see us going down the "stack" path. The
problem
is that we cannot possibly know what's best for our users' applications.
Just as an example, in all the years that I've been developing Java web
apps, not once have I been in a position to pick up an ORM package and
use
it for my app. Instead, the apps are all built upon custom APIs or
services
frameworks. With a "stack" solution, the first thing I would have to
do it
figure out (a) if and (b) how I can remove the pieces of the stack I
don't
want or need, and what the implications are for doing so.
I know the response to this is going to be "but we want to provide the
greatest leg up for our users", but the question is, what proportion
of the
framework's potential user base will really be able to use the entire
stack
that we might provide? And for those who can't, how will we convince them
that they can unplug / replace the bits they don't want or need without
having to know the internals of the framework? For that matter, how
will we
convince ourselves?
--
Martin Cooper
On 9/6/06, Ted Husted <[EMAIL PROTECTED]> wrote:
For Struts Next, here are my personal goals.
* xStruts.
I would like Struts to become a framework so elegant that developers
working in other environments will want to implement it too. IOW, the
xUnit of web development frameworks.
Overarching vision: "Share the wealth."
* Struts DAO.
Today, the framework seamlessly integrates XWork, OGNL, and Spring,
and FreeMarker with JSP or Velocity. Through Results, we integrate
with JasperReports, PDF, JFreeCharts, and so forth. Next, we should
look toward providing the same type of seamless integration with
Cayene, iBATIS, JDO, or as a third-party option, Hibernate.
Overarching vision: "Play well with others."
* Struts Stack.
Bundle a proven set of extensions with Struts Core to create a
complete MVC web development development, powerful enough to create
"best of breed" applications, like Confluence and Jive, "out of the
box". Extension could include packages like Display Tag, Struts Menu,
Acergi, Web Flow, and iBATIS or Cayenne (Sadly, Hibernate is still
LGPL), along with an example development platform featuring Eclipse,
HSQL, Jetty, Subversion, MailMan, and Trac.
The Stack would be "proven" with a range of practical example
applications, backed by realistic requirements and use cases.
Overarching vision: "Soup to nuts."
* Struts Plugins.
Right now, Struts 2 is a "pluggable" framework. We start with a set of
interfaces, and plugin a proven, general-purpose implementation. As
it stands, we implement plugins using two approaches, "bootstrap" and
"config-behind-code". In both cases, the "plugins" are just XML
documents. Some bootstrap documents are bundled in the JAR, others are
provided by the application.
At startup, the framework is hardwired to look for the "bootstrap"
configuration documents, like struts-default.xml (packages),
default.xml (validators), struts.xml (custom packages), which can in
turn bootstrap other configuration documents.
At runtime, the framework looks for "config-behind-code" plugins, like
"Classname-validation.xml", "Classname-conversion.properties", and
"Classname.properties" (localization).
I'd suggest that we try to adopt a consistent approach to plugins so
that everything is configured the same way. Ideally, we should not be
tempted to include "optional" members that only work when we provide a
third-party JAR with our application. We should be able to drop in a
plugin configuration as easily as we drop in a JAR.
By utilizing a clear plugin strategy, we can avoid distribution bloat
while making it easier for both novice *and* expert developers to
create the optimum environment for any given application.
Overarching vision: "Less is more"
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
