Comments interspersed.
----- Original Message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 14, 2001 5:44 AM
Subject: Updating Site for Struts 1.1
> I'd like to make some updates to the Web site to move us squarely into
> the 1.1 time frame. Here's what's on my list. Additional suggestions
> most welcome.
>
> + Setup a separate menu section (at the left) for the 1.1 items (User
> Guide, JavaDoc, TODO, Proposals).
Currently, there are only two items in the menu that are not 1.1 related
(User Guide and 1.0 Release Notes). Are you proposing separating only the
documentation part of the menu into two sections, one for 1.0 and one for
1.1, or the whole menu?
If the goal is to have a more complete set of pages for both 1.0 and 1.1 on
the web site, then perhaps we should think about having the 1.1 (or latest,
which is currently 1.1) pages at the site entry point, and have a link to
the latest-stable-release "sub-site", which would look very similar but
contain only 1.0 data.
I've seen numerous messages on struts-user, and entries in bugzilla,
resulting from confusion about what the web site actually documents that
clarifying it definitely gets my +1!
> + Emphasize that 1.1 is in development, and 1.0 should be used in
> production. Clarify what is new in the nightly build (and maybe try a
> "patch" jar for things like the indexed tags).
I'm definitely +1on the first two points, but I'm not so sure about the idea
of a "patch" jar.
> + Place html versions of 1.0 items in the nightly build (so we can also
> keep them on the Website ;-)
Do you mean check in the generated versions of the 1.0 docs, so that they
can be included in the struts-documentation.war and therefore land up on the
web site? If so, +1.
> + Conform the Struts Resource page with what is listed at <
> http://husted.com/about/struts/resources.htm >
I'm not clear on what you mean by "conform", since I can see two
alternatives. Option 1 would be to clone your site into Struts Resources, so
that they both contain the same material. Option 2 would be to take your
page, turn it into the Struts Resources page, and "reset" your page to
simply refer to the Struts page. Subsequent additions might then be made to
your page, which would later be merged into the Struts page.
Of these, I would prefer option 2, because (a) resource information would
not be duplicated, and (b) it would be easier for people to identify what is
unique to your site (and therefore new).
> + Add some general API links, like those in the API section here: <
> http://husted.com/about/struts/links.htm#apis >
+1
> + Start an area where we can post reviews or articles about the growing
> number of Struts contributions.
+1
> + Add a FAQ area, based on the material here: <
> http://husted.com/about/struts/FAQ/index.htm >
>
> We also have the jGuru FAQ at our disposal
>
> http://www.jguru.com/faq/home.jsp?topic=Struts
>
> so we might want to be choosey about what questions we put in our FAQ
> (the truly frequently asked).
+1 on being really choosey. :-) Also, we would obvously want to link to the
JGuru FAQ from our own.
> + Create standalone Digester and Bean-Utils Developers guide with
> Struts-specific information, and then link to the Commons for general
> information.
Not sure about this. Can you elaborate on the kind of Struts-specific
information you have in mind? Also, the individual Commons projects do not
seem to publish any documentation on the web site, so there are no developer
guides available as there were prior to those components moving from Struts
to Commons. I would definitely be +1 on having documentation available on
the Commons site.
> CONTRIB AREA
>
> I'm very unsure about how we want to position packages like Tiles and
> the Validator. These can be used outside of the framework, and it seems
> like a disservice to bury them in our distribution.
>
> One idea would be host these in a neutral area, where they will get even
> more exposure, and then maybe carry top-level, Struts-specific tutorials
> here.
>
> Of course, since David and Cedric do the most work on these, they also
> have the most say. I think either would be a good fit at Taglibs or the
> Commons, but will keep my peace if the primary Committers want to keep
> them here.
>
> I just want to be sure that we learn the lessons of Turbine, and make it
> obvious where the "core" framework ends and the (very cool) options
> begin. I'd also like to send a message that Struts plays well with
> others, and that we fully expect that developers will plug other
> pre-built packages into their application.
The Ant project has a couple of ideas worth looking at (although I don't
think they've got it completely right for what we might want). They have an
"External Tools and Tasks" section on the web site for this type of thing,
as well as an "Optional Tasks" section in the main Ant documentation. All of
the optional tasks are distributed together within an optional.jar file. I
don't think this is the best fit for what we want, but it might help drum up
some alternative ideas.
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/about/struts/
--
Martin Cooper
