As I've gotten into this, I've noticed something with how we
structure documentation. Today, we do this:
<release-number>/
netui/
...
apidocs/
classref_netui/index.html
classref_controls/index.html
taglib/index.html
and so on. Basically, there are the Forrest documents in netui/ and
the other documentation under apidocs/. This makes sense from a build
perspective, but it doesn't make much sense from a packaging
perspective because the NetUI documentation is spread throughout the
documentation directory.
I'm going to look at whether it's possible to do something like:
<release-number>/
netui/
reference/
apidocs/
tagref/
and so on. Not sure if this is even possible in Forrest, but we'll see. ;)
Eddie
On 1/23/06, Eddie O'Neil <[EMAIL PROTECTED]> wrote:
> All--
>
> I'm planning on taking a pass through the Beehive documentation in
> the next week to accomplish a few things:
>
> - canonicalize some of the names, for example renaming
> "controls_tutorial.xml" to "tutorial.xml"
> - adding tutorial links to each of the sub-parts
> - moving all of the WSM documentation into a trunk/wsm/docs directory
> - fixing up lots of the controls documentation to:
> - rename JSR-175 to Java 5 metadata -- who cares about the JSR number :)
> - rename "corporate developer" to "application developer". it's
> more descriptive this way
> - break the Controls Programming document up into smaller pieces,
> one per topic. Am guessing 9 topics or so
> - adding content for:
> - using NetUI data grid sorts and filters
> - using the Controls test container
> - adding a sample for:
> - NetUI data grid sorts and filters
> - adding real release notes for 1.0.1, now with links to JIRA!
>
> Other documentation thoughts / ideas welcome.
>
> Eddie
>