Rick, I have been using the following package layout for a while and it seems to make sense.
For example, let's say the foo web application consists of various sub applications like account, store, product download, etc.... com.acme.applications.web.foo.account.action com.acme.applications.web.foo.account.service com.acme.applications.web.foo.store.action com.acme.applications.web.foo.store.service etc... May not be the best way, but like I said, it seems to make sense and it works for me. robert > -----Original Message----- > From: Rick Reumann [mailto:[EMAIL PROTECTED] > Sent: Friday, September 17, 2004 2:42 PM > To: Struts Users Mailing List > Subject: I'm going back to just using regular Actions.. a question > > > 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]
