Forgot to mention, although you probably guessed... Any other class specific to the app that doesn't fit any of the categories (things like helper classes used in may different Actions) are in com.company.project.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Fri, September 17, 2004 2:54 pm, Frank W. Zammetti (MLists) said: > I personally use #3. In fact, all my projects have a pretty > internally-standard packaging scheme (my own creation)... > > com.company.project > | > *---actionforms > | > *---actions > | > *---business > | > *---config > | > *---daemonthreads > | > *---exceptions > | > *---listeners > | > *---plugins > | > *---webservices > > actionforms and actions are self-explanatory, business is any business > delegate class (i.e., anything specific to the app but not tied to the > presentation), config is any app-specific configuration classes, > deamonthreads is any background threads, exceptions is any custom > exception classes specific to the app, listeners are any HTTP listeners, > plugins are any Struts plug-ins and webservices is any Web Service-related > code. > > All but the first two are optional in any given project. Any class that > is shared with other projects in is com.company (possibly in a package > underneath that). > > It's just what I've settled on... Works for me. > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > On Fri, September 17, 2004 2:41 pm, Rick Reumann said: >> After thinking about the flavors of Dispatch actions I use, and after >> having used them as my primary type of Actions for the past 3+ years, >> I've decided to go back to just using regular Actions. I like the >> modular self contained Actions. >> >> My question is more of design practice for those that just use standard >> Actions. How do you design your packages? For example... >> >> EmployeeUpdateAction: >> >> 1) package com.acme.ui.action.employee; >> >> or >> >> 2) package com.acme.ui.employee.action; >> >> or just put them all in one package: >> >> 3) package com.acme.ui.action; >> >> I'm leaning towards option 1 myself. Other thoughts? >> >> -- >> Rick >> >> >> --------------------------------------------------------------------- >> 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]
