struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <>
Subject Re: struts-user Digest 29 Jan 2003 03:57:51 -0000 Issue 2580
Date Wed, 29 Jan 2003 09:51:54 GMT
 > We are currently developing Struts apps and incorporating Scaffold
 > code into them.
 > Firstly, I was wondering if anyone else out there is using Scaffold
 > code and what comments they have on their success or otherwise with
 > it?
 > Secondly, with the latest release of Struts (1.1b3), Scaffold code has
 > been packaged into the contrib section.  However the commons-scaffold
 > components are not there.  They are in jakarta-commons-sandbox but
 > only the source in the CVS repository.  Should commons-scaffold be
 > somewhere in jakarta-commons now that scaffolds is being packaged with
 > Struts 1.1b3 and should there be a built version of this code
 > somewhere?

Scaffold is the toolkit I use to develop my own Struts application.
There's some coverage of it in Struts in Action. The built-version used 
in the book is available at the Struts SourceForge site.

(Like the Velocity-Tools stuff, Scaffold is "on display in the bottom of 
a locked filing cabinet stuck in a disused lavatory with a sign on the 
door saying 'Beware of the Leopard'." [No calls folks, this one isn't a 

Like many things, the toolkit  grew in the telling. Right now, I'm going 
through it and looking for things that I might be able to disburse to 
other Commons packages.

I'm also working on a new set of packages based on the terminology from
Martin Fowler's new Enterprise Architectures book. Many of the Scaffold
classes are based on what Fowler calls a "Domain Layer", along with some
other goodies like his "Repository" and "Data Mapper" packages. Most of
the code and concepts remain, just new nomenclature.

So, Scaffold is alive and well, and undergoing some active refactoring
right now. Once Struts 1.1 ships, I'll see if we can setup a procedure
for releasing contributions. (But if I were bring anything like that up
now, Mr. Turner might threaten me with bodily harm. There's talk that he
carries a whip =:])

One twist I'm trying now is to delegate more to the validate method. The
idea being that, to do its job, validate must already know quite a bit
about the use case at the other end of the instant action. From an
architectural perspective, validate is the prime position to create
whatever business object we may need to pass up to the domain layer. The
Action can then just pull off the domain object, pass it along to a
service object or repository, and ferry back the response. It's very
easy to write standard Actions to do that sort of thing, so that the
programming effort in Struts-specific classes is minimized.

One pipe dream is to have the business object use the Commons Validator.
The ActionForm could then just instantiate and validate the business
object ("inversion of control"), passing back any message if it fails.
(Which is why I was eager to get the Messages setup in the Commons now.)

It's my feeling that, overall, Struts is very excellent example of a
controller-based architecture, applied at the presentation tier layer.
The next trick is to come up with a generic enterprise architecture that
uses the same patterns but does not presuppose a web presentation. We
could then create our applications using this hypothetical enterprise
framework and link it seamlessly to Struts. McClanahan and Fowler have
given us the tools and vocabulary, all that's left is the sweat, tears,
and lots and lots of unit tests =:0)


-- Ted Husted, Struts in Action <>

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

View raw message