Contributing to the documentation isn't any different than contributing to the codebase. Just figure out where it should go and submit a patch or enhancement request through bugzilla. A list of which classes must be extended and which can be used as-is (whitebox vs blackbox) could be handled in the newbie FAQ. Or we could add a new section to the User Guide. The catalog document on my site is in HTML right now, but if someone converted that to XML, we could move that over to the Struts site and expand on that. Whoever does the work gets to make the decision.
There is also a lot of material that can be mined from the list. For example, Craig posted some nice material on populating ActionForms on the Dev list last week. If someone took that material, poured it into XML, and submitted it to Bugzilla, we'd be on our way to a patterns document. As a rule, 90% of anything Craig posts is a FAQ waiting to happen. Someone just needs to take the initiative to convert the exchange to a documentation entry. Patches to the Javdocs are also welcome. The Struts Javadocs are a wealth of detail and should be considered the primary source of information. Moving forward, I'd like to expand on the Developers Guides <http://jakarta.apache.org/struts/doc-1.0.2/api/org/apache/struts/taglib/bean/package-summary.html#package_description> as a replacement for the User Guide. We can then use FAQs and working examples <http://sourceforge.net/projects/struts> to fill in the blanks. As it stands, maintaining details in the User Guide and in the Javadocs is becoming a maintenance burden, and the Developer Guides model seems like a better way to go. One thing to keep in mind is that Struts "grew in the telling". There are many places where the evolution of the codebase has caused functionality to overlap. Someone realizes something is too hard to do and so they introduce an easier way to do it. But since many people have already done it the hard way, we can't change the old t way without breaking a lot of code. The 1.1 codebase would be much simplier if not for the 1.0 compatibility issues. But we can't desert all the 1.0 production applications on a "point release" and so we have to deal with the legacy issues. -Ted. Phase Web and Multimedia wrote: >Ted, > >I totally dig your catalog and i have been examining Artimus. Stellar piece >of work btw. I would love to receive more clarity towards which classes are >best extended for what functions. For example, there are things that i can >do in an Action class that can also be done in a RequestProcessor. But for >portability, plugability and efficiency which is the best to extend for >what. Also, it would be good to list which classes are made to be extended. >There are four main ones that I can think of off the top of my head... >RequestProcessor, Form, Action and ActionServlet. > >I would be totally willing to provide some pattern docs, but i am afraid my >design patterns would be weak in comparison to what you have assembled in >catalog. I would also be totally willing to receive various design patterns >from people out there that are using struts and assemble them into xml. It >would both educate me and give me an opportunity to give back to a project >that has provided so much. Anyways, where do i sign-up and what are the >qualifications? > >Brandon Goodin >Phase Web and Multimedia >P (406) 862-2245 >F (406) 862-0354 >[EMAIL PROTECTED] >http://www.phase.ws > > >>-----Original Message----- >>From: Ted Husted [mailto:[EMAIL PROTECTED]] >>Sent: Sunday, August 18, 2002 7:41 PM >>To: Struts Users Mailing List >>Subject: Re: Struts Community is going crazy! :-)) >> >> >>If anyone wants to start writing up patterns and submitting them to the >>project (preferably in XML), I'd be happy to shepard them into the >>documentation. But someone has to be willling to do the work. This is an >>open source project, and everyone who uses Struts is part of the team. >>We don't take your money, but we will take your contributions =:0) >> >>If anyone is in the mood to help with the documentation, but isn't up >>for cataloging patterns, there are a number of 1.1 sections still marked >>[:TODO:]. There are also still a number of open questions on the >>newbie FAQ. >> >>http://jakarta.apache.org/struts/newbie.html >> >>-Ted. >> >>Phase Web and Multimedia wrote: >> >>>I have seen so many extensions and ideas being developed around >>> >>struts. One >> >>>of the things that I have noticed is that there are a lot of different >>>apporaches being taken towards using Struts. In my own conversations with >>>colleagues I have found that there is a fair amount of confusion mounting >>>over proper design patterns within and extending struts. >>> >>>I don't know if there is a base set of "suggested" patterns that >>> >>have been >> >>>layed out. But, maybe we can collect the wisdom of the >>> >>contirbutors in order >> >>>to avoid development of heavy or misplaced extensions or apps. I know Ted >>>has laid down some stuff for us to view in his "Catalog". But, there have >>>been several things I've seen popping up. For example, The debate used to >>>be... do i extend the Action class or the Action Servlet... Now, >>> >>we seem to >> >>>be extending the crap out of the Request Processor. The danger >>> >>is that there >> >>>many ways to implement an idea and it could work in the extended Action >>>class or the extended RequestProcessor. But, why should we extend the >>>ReqeuestProcessor or the Action class. What extensions are best >>> >>run against >> >>>each of the extendable classes within struts. Also, I have seen a >>>processPreprocess() method that is being used in the >>> >>RequestProcessor class. >> >>>What is the best use for processPreproccess()? >>> >>>Finally, from what i am seeing of the struts codebase is that it >>> >>is starting >> >>>to get really bulky. I thought the goal was to remain lightweight and >>>provide hooks for extensions. I am seeing all the nifty extensions being >>>developed and put into the base. Isn't there a way we can provide >>>configurable extending? Rather than work on making the base include every >>>good extension, why not make the base easier to extend and provide a >>>standard set of hooks that can be used to access the internals. I think >>>maybe I'm all washed up on this. I have been using struts for a >>> >>year now and >> >>>I am constantly wondering what the heck is going on. Everyone seems to be >>>doing things different and it's getting difficult to build a >>> >>project that is >> >>>going to have some longevity. >>> >>>In summary, I am seeing people develop extensions that conflict >>> >>and do not >> >>>play nice with other extensions. I see Action classes being >>> >>extended and I >> >>>see RequestProccessor classes being extended which are making >>> >>for a mighty >> >>>mess when trying to get them to play together in a single >>> >>project. It just >> >>>seems that there needs to be a little clarity on extending >>> >>practice/purpose >> >>>and we need to get some clarity or development focus on an >>> >>easier and more >> >>>configurable extending of struts. >>> >>>Is anyone else thinking what I am? >>> >>> >>>Brandon Goodin >>>Phase Web and Multimedia >>>P (406) 862-2245 >>>F (406) 862-0354 >>>[EMAIL PROTECTED] >>>http://www.phase.ws >>> >>> >>> >>>-- >>>To unsubscribe, e-mail: >>> >><mailto:[EMAIL PROTECTED]> >> >>>For additional commands, e-mail: >>> >><mailto:[EMAIL PROTECTED]> >> >>> >> >> >>-- >>To unsubscribe, e-mail: >><mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: >><mailto:[EMAIL PROTECTED]> >> >> > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
