We can still provide FAQs and HOW-TOs, as we do now. * http://struts.apache.org/faqs/index.html
But as to the foundation documents for each subproject, we need to recognize that our resources are extremely limited. The User Guide as it stands is very hard to keep current, and Committers are always wondering where to document some new task. -Ted. On Tue, 21 Dec 2004 08:32:21 -0500, Phil Steitz wrote: > The one thing that might be lost in this approach is the task focus > -- i.e., the "Building..." view. An alternative might be to add > something like what maven has here > <http://maven.apache.org/reference/project-descriptor.html> for the > struts-config DTD and leave the User Guide strucutured the way it > is, but including links into the relevant sections of the "DTD > reference". That way users would have both a quick tech reference > and a guide useful for introducing / understanding app development > with struts. > > Just my 2c. > > Phil > > > Ted Husted wrote: >> Documentation for 1.3++ has come up in a couple of threads, and I >> wanted to jot something down before I forgot. >> >> In the 1.3.x series, we are moving taglibs to a separate project, >> which gives us a chance to revisit the documentation. >> >> For core, I would like to use the DTD as the basis for the >> documentation. (We even have an enhancement ticket to do so.) >> Sections 0 and 1 of the User Guide could stay as is, but after >> that, we could march through each element the DTD, combining the >> existing DTD material with stuff we have scattered throughout >> sections 2 - 4. (In other words, expand 5 to incorporate 2-4.) >> >> 0 - Preface >> 1 - Introduction >> 2 - struts-config.xml >> 3 - Form Beans >> 4 - Exceptions >> 5- Forwards >> 6 - Action Mappings >> 7 - Action >> 8 - Controller >> 9 - Messager Resources >> 10 - Plug Ins >> 11 - web.xml >> 12 - Getting Started >> >> Then do the same for the Validator and Tiles DTDs. >> >>> From an all-important maintenance perspective, we would update, >>> add, or delete User Guide sections as corresponding changes are >>> made to the DTD elements. >>> >> When available, we could also link to corresponding Developer >> Guides (JavaDoc package descrptions). Right now, we have these >> for the Validator and Util package, but we should also have >> Developer Guides for Action, Config, and Upload, to help pull >> people into our very excellent JavaDocs. >> >> Again, from a maintenance perspective, we would update, add, or >> delete Developers Guides as changes are made to the corresponding >> Java packages. >> >> * User Guide == DTD >> * Developers Guide == Java Packages >> >> >> For taglibs, what we have works for me. We could just move the >> Bean, HTML, Logic, Nested, and Tiles Developer Guides and API >> references into the new subproject, and add an overview. >> >> -Ted. >> >> >> ------------------------------------------------------------------ >> --- To unsubscribe, e-mail: [EMAIL PROTECTED] For >> additional commands, e-mail: [EMAIL PROTECTED] >> > > -------------------------------------------------------------------- > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
