struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [PROPOSAL] Modular Struts Examples
Date Thu, 03 Jul 2003 20:29:00 GMT

On Thu, 3 Jul 2003, Vic Cekvenich wrote:

> My point was a shade on the other side. Yes Struts can show integration
> to do 100's of things out there.
> But at its core, Struts is a controller framework.

Right now, it's in particular a "front controller" framework, in design
pattern terms.  That's one of the areas I would personally like to see us
do some innovation.

> Action Event Object execute signature- instead of the execute signature
> with 4 arguments, have a single object containing the 4 objects.
> This reduces people new to Struts creating properties in action, and
> allows same execute signature for TilesAction, etc. The code looks a lot
> cleaner. bP does this (as I think does Expresso)

No matter how technically worthy such an idea might be, this isn't going
to happen in a 1.x train, due to backwards compatibility expectations.
This is part of the responsibility that goes with being a widely deployed
and utilized framework -- we have to protect the investment of people who
have built on top of the existing architecture.  If we only had a few
users, we would be more free to do stuff like this.  But according to the
Apache web site stats (unofficial, but seem like they're pretty accurate)
we get ~75,000 downloads per month, and that was BEFORE 1.1 went final.

If we're willing to look at changing the fundamental APIs (and I think we
are in a 2.x train), there is a lot more we can do to make Struts better
than just this kind of change -- I'd rather look at the overall
architecture more holistically, instead of incrementally, when making
decisions like this.  For example, I will shortly be done with a pretty
radical proposal for the "decomposing the request processor" conundrum
that has been discussed a lot lately on STRUTS-DEV.

Incremental change is great for improving implementations.  It's not so
great for modifying fundamental APIs.  To do the latter well, you need to
be prepared to think outside the box, and even re-invent yourself on

> protected List _list in FormBean. As Husted's book points out (and bP
> implements), it is nice to store data in a protected _list. (I am sure I
> took it out of context) People mostly work with a tabular recordset,
> rows of columns, eg: List of Maps. There are many ways of getting DAO
> data to FormBean, but a good idea is to store the rows as a _list.
> People that extend the ValidatorFormBean can then write their own
> getValue, setValue and beann getters/setter, it nuges people in right
> direction to store data agnosticly. (Ex: MQ gets results, remaped via
> magic to formBean, and stores in a list).  Things like indexed
> properties become easier then ... and best view in JSP world is display
> tag, works with collection. Note that I would not implement the methods,
> just leave it like that, protected _list, a place to plug into.

As you well know :-), you and I don't totally share a vision of what a
form bean is for, and what it's not for :-).  However, the recent progress
on JavaServer Faces clearly indicates that Struts's form bean approach,
and total lack of any real UI component model, needs to be addressed.

I'd actually rather address it by focusing on the controller (as you
suggest), and let all the view-layer considerations be separated as well.
I think that form beans, by themselves, are too limiting as a long term
abstraction for server-side view state.

Just as an example of this, look at where JavaServer Faces is today, with
respect to the concepts behind form beans and actions:

* You can use one form bean per page, or more than one -- your choice.

* You can combine the form bean data with your "action" class
  (the way that WebWorks does it) or keep them separate -- your choice.

* You can ask for ANY bean to be automatically instantiated on demand,
  not just form beans.

The technology train is passing us by.  We're not going to be able to
catch up with simple incremental changes.

> Maveric instead of Ant for build. My argument is this. CVS out
> CommonsSQL and use Maverick to build it. Sexy!
> It auto downloads all the other jars it needs. People can target any
> thing very easily. The build process becomes simple and fun.
> (I do not have this code, but could)

In the Apache world, Maven provides similar sorts of capabilities, and
does not require you to give up the ability to use plain old Ant (Maven
can generate a build.xml file for you).  If we're going to switch, I'd
rather go that direction (if the Maven folks would ever ship a final
release, at least).

Improving the build process is definitely needed, but that's mostly for us
as developers, not for users.

> Required in DTD of sturts-config the request processor element. - This
> nudges expert users in extending Struts in the right place, it exposes
> the right place overlooked.

In the "workflow" component of jakarta-commons-sandbox, one of the things
I really liked was using XML namespaces as an extensibility mechanism.  It
seems like a natural way to let people integrate extensions of their own
into an existing standard configuration file format.

However, DTDs are not powerful enough to allow for this -- you have to go
to XML Schema (or something equivalent) to support it (the way that all
the deployment descriptors in J2EE 1.4 are going), or else give up on the
idea of validation at all.  That's too big a price to pay.  And, as long
as we're based on Servlet 2.2 / JSP 1.1, we can't really get away with
requiring schema support, so it's tough to move forwards on this one in
the short term.

> Reduce number of actions and formbeans in Struts. It could be consolidated.

I can see what you're saying on form beans, but what do you mean by
"reduce the number of actions"?

> DAO - OK, here I walk a fine line.
> Struts is model agnostic. But slowest part of J2EE is DAO; and Struts is
> the most popular J2EE framework. No one outside of Struts-dev can fix
> this. If there can be an interface (I know, if you change it.... bla,
> bla) for a DAO, that is KISS, but could work for JDO, EJB, Hibrenate,
> RowSet, MQ, etc. etc. It would enable people to easily plug and play a
> model. I do not care what the signatures of this DAO are other than it
> must allow ANY DAO implementation to be used and shoud be unit testable
> for CRUD.
> Craig, I realy realy think that only you can make this happen. (That
> registration of DAO for JSF I did not like, interface is KISS)

There is more than one "right" way to integrate persistent data and
business logic into a web application, DAOs being only one of them.  There
is more than one "right" way to design DAOs, depending on your particular
requirements.  Whatever we do in Struts needs to recognize that it is not
going to be possible to shoehorn everyone's requirements into a single

For the particular case of tabular data, we should also be paying
attention to recent innovations in JDBC RowSet Implementations (JSR-114)
that just went to Public Review Draft in the JCP process.  I would expect
to see early access RI code for this stuff shortly, and it will be
interesting to see how well those folks did on a standardized abstraction
to rows and columns, with much stronger support for disconencted operation

But rows and columns doesn't cover all of the world's needs either ....

> Display tag- (Talk out of bouth sides of your mouth) Yes Stuts is view
> agnostic. But Display tag commiters are trying to make it updateable
> AFAIK. Download the display tag war and run examples. This is the
> colosest thing to DataGrid in JSP. Put it in Struts to get focus (and
> then slowly move to taglibs).

I am not personally interested in being in the proprietary custom tag
development business at all any more ... JSP 2.0, JSTL, and JavaServer
Faces have made (or will make, in the latter case) further innovations on
non-standards-based tag libraries a waste of long term time.  We need to
maintain and enhance the existing implementations, and fix the things that
are wrong with them -- but the future is going to be based on the standard
APIs, if we want to continue to be a mainstream platform.  We need to
continue to welcome and integrate the new technologies (as we've done with
JSTL and Faces so far).

Recast the display taglib (or anything else in the same space) as
JavaServer Faces components and I'll be interested in it.  Incorporate JSF
component libraries from your favorite development tool or open source
project, and I'll be interested in it.  Suggest that we create some of our
own value-added components based on Faces (so that we're not limited to
just JSP, and not limited to just rendering HTML), and I will be
interested in it.  Continue to innovate on top of the current form bean
architecture, and I'm probably not going to be interested in it for the
long term.

Other Struts developers, of course, can speak for themselves.

> Anything else out of bP that somoene likes. (Ex: j2Ee + Sturts security
> example, multi row updates, events - like action changed event for
> session clean up)

There are undoubtedly some ideas from bP (and other things built on top of
Struts) that can be harvested in a 1.x time frame, now that we got 1.1 out
the door.  A lot of resistance to this in the past has been based on
wanting to get that (1.1) done, not by concerns about technical merit or
suitability for inclusion.

(Regarding examples, having lots of small-to-medium examples seems better
than having few huge ones; but that's a topic for the other thread.)

My only concern goes back to the comments about DAOs above -- when there
is legitimately more than one approach to dealing with a particular issue,
you want to be careful about baking in one-and-only-one approach into the
fundamental architecture.  And, when there are standard APIs in the same
space of endeavor, you ignore them only at the risk of becoming
non-mainstream in the long run.

> Target servlet 2.3 and JDK 1.4. - There are now dependencies on 2.3 and
> more comming. Almost no one uses Tomcat 3. TC 5 level JSP 2.0 looks like
> more fun. People that want 2.2 or 1.3 could rebuild, or they can keep
> using solid 1.1. A small KISS step. By the time 1.2 comes out....

For Struts 1.2, we have already agreed to stay with Servlet 2.2 / JSP 1.1,
but change our release cycle to do incremental releases much more often
(the way that Tomcat and the HTTPD server do it nowdays).  Besides a
continuied commitment to backwards compatibility in APIs, this puts
restrictions on how frisky we can get with changes to old stuff (adding
new stuff actually becomes easier with the new release cycle approach).

For Struts 2.0, I think we should actually skip Servlet 2.3 / JSP 1.2, and
go straight to Servlet 2.4 / JSP 2.0 / JSTL 1.1 / JavaServer Faces 1.0 as
the base platform.  Because of the lengthy gestation period for J2EE 1.4
as a whole, it won't be long after 1.4 goes final that we'll have lots of
containers available to host such apps.  It doesn't make sense to do any
fundamental architectural improvements in the core Struts APIs without
recognizing that this will be the commonly deployed platform by the time
we get done.

Servlet 2.4's changes (request lifecycle listeners, and the ability to
execute filters on RD calls) are not earth-shattering, but they are
useful.  JSP 2.0's changes, on the other hand, are very fundamental (if
you're using JSP as the basis for your view technology), and eliminate the
need to use Java code for lots of things where it is used today.  For
example, a page author can point at a chunk of JSP code and say, in
essence, "please make a custom tag out of this for me".  And, of course,
EL expressions are evaluated anywhere in the page (even static text), so
tags like <bean:write> basically lose their reason to exist.  And, for the
cases where custom tags written in Java are still required, the new
SimpleTag API is *substantially* easier to write aganst than the current
Tag/BodyTag stuff.

> I will do the legwork on any of these, if a single dev is interested in
> applying the diff., but most are trivial and do not need man hours. The
> last one I hope makes it for the 1.2 release

Nobody can decide whether or not to apply a specific change without seeing
precisely what you're proposing to modify.  A lot of the things you've
suggested in this email would break backwards compatibility, and thereby
earn a -1 for implementation in 1.2, but might well make sense in a 2.0

> .V


> V
> >>
> >
> >
> > Craig
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message