struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: The best way for learning struts (stupid question)
Date Fri, 17 Jan 2003 05:02:08 GMT
Snipping to just the questions.

On Thu, 16 Jan 2003, joni santoso wrote:

> >* Design patterns (at the programming level)
> any good sites for learning this? I read already the
> theoretical ones but at the programming level, sometimes
> I'm still confused to use which DP.

The classic text (and the one that really popularized the notion of caring
about the "design patterns" concept) is by four authors colloquially known
as the "Gang of Four" (or GoF):

  Gamma, Helms, Johnson, Vlissides, DESIGN PATTERNS:  ELEMENTS

Punch "design patterns" into Google or Amazon and you'll find lots of info
sources, including many focused on Java or J2EE (servlet/JSP are the
standard web tier technologies for J2EE).

On "when to use which patterns", it's a skill that comes from practice and
experience.  However, I'd start by seeing if your problem space is similar
to things in the "Applicability" section of many pattern descriptions.
And check the "Consequence" (both good and bad) to see if applying this
pattern would help you towards better results.

> >
> >* Unit testing concepts and test-first design (JUnit is a
> >wonderful
> >   tool for this in the Java space)
> I learned this too. But, it seems that there're a few
> tutorial on JUnit. Can anyone here refer me?

There's some philosophical and introductory stuff on the JUnit web site
(  But JUnit is primarily a tool to implement a philosophy
-- the philosophy of "unit testing" as a discipline.  You might want to
search for that term to get some references.

One thing you might want to do is download the source code to a small bit
of code that is heavily unit tested (such as commons-beanutils that Struts
uses), and see what we did -- the intent was to write tests for every
possible invocation of every possible method.  Having the tests in place
does two primary things for us:
* Documented proof that the method being tested behaves
  according to it's (Javadoc) specification
* Protection from future developers making changes and
  inadvertently changing the behavior that users of the
  code depend on.

You can grab a source distro of commons-beanutils (pick any recent nightly
build) at:

and look in the "src/test" directory for the unit tests.

Unit testing is also one of the foundations of a development approach
called Extreme Programming (XP), so there will be lots of pointers and
examples in the information about XP as well.

> >* Architecture of the web (particularly how HTTP, HTML,
> >and
> >   JavaScript work)
> can you elaborate more? As a Software Developer for mostly
> web, I know how the JS and HTML work. But why I should
> know about HTTP?

Well, the web runs on HTTP.  The facts that HTTP is synchronous
(request/response) oriented, and stateless, are critically important.
The facts of how security and cookies work are driven by the HTTP
standards.  Little details like the fact that HTTP headers are sent at the
beginning of a message, so you can't usually add them at the end of your
servlet, will help you avoid lots of frustration.

It's sort of like learning to drive -- if you focus on the mechanics of
steering a car, but don't understand the driving laws in your country,
you're likely to have a lot more problems than if you had studied both

> >
> >* The Servlet API -- foundation to every Java-based web
> >application
> done. Though, I don't explore them thoroughly. Only, when
> I meet a very special case like how to limit the number of
> access a user can make to the web app, delivering image on
> the fly, creating an excel file, etc.

It's fine to learn the details as you need them, but if you haven't done
a pretty complete overview, then how do you know what's there that you
*haven't* needed yet?  Servlets are foundational to understanding JSP.


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

View raw message