Personaly, I find it most useful to organize everything along conventional functional module or package lines. Things that are used together should be packaged together.
At some point, these functional divisions might also made into actual Struts modules and developed independantly. (This prospect should figure highly in any organizational scheme.) Within any application, there are tasks that are used together and tend to form subsystems. Often, these tasks are handled by the same developer(s) within a larger team, and also tie into the applications life-cycle and overall organization. For example, an auction application might have a registeration package, a searching package, a bidding package, and a fulfillment package. For the JSPs, I generally use a /pages folder off the root, and then organize by package beneath that. Something like /pages ./reg ./bid ./find ./buy On the Java source side, there would be corresponding .reg, .bid, .find, and .buy packages Which I think might all fall under your Conventional Theory category. I believe this is also the way the Struts source files are organized. The Action classes are all kept together, since they all work together to form the control layer. Other classes were dispatched to the util package (and then off to the commons). The validator has it own pacakge, as does tiles. We tend to put suffixes like *Action and *Form on classes, but that stems from the *Bean naming approach, rather than the package. Also keep in mind that organizing files for Struts is not any different than organizing them for any Model 2/MVC architecture. BTW, whether putting pages under is WEB-INF is "best" or not may depend on what container you are using. It is *not* always an option. It also means that you might have to separate your JSPs from other assets that need to be outside of WEB-INF, like HTML files, images, and stylesheets. Like any strategy, this approach has consequences, both good and bad. -- Ted Husted, Husted dot Com, Fairport NY US -- Java Web Development with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services [EMAIL PROTECTED] wrote: > > I have been playing with UML and trying to find a good way to do the > upfront design of a struts based application. Has anyone done this > already and have any suggestions? I know the use-cases can pretty much > stay the same... > > I am also putting together a document on the best way to go about > struturing your directories under struts... If anyone has any > suggestions I would love to hear it... > > I already have stuff like JSPs under the WEB-INF and stuff. I am trying > to work out the best way to organize all the packages in the src > directory... > > Should they be by purpose of the objects like (conventional theory) > > com.ebind.hrdata.people; > com.ebind.hrdata.companies; > com.ebind.struts.create; > com.ebind.struts.search; > > or more along the lines of struts: > > com.ebind.peoplefinder.search; > com.ebind.peoplefinder.create; > > We've got two small projects done wth struts and the next ones will be > more complex so I want to get the best practices down (I've printed and > read the husted site a few times already) > > Any thoughts would be great - and I will drop the document out here when > its done > > -- > 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]>
