Re: I'm going back to just using regular Actions.. a question
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]
Re: I'm going back to just using regular Actions.. a question
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]
Re: I'm going back to just using regular Actions.. a question
Frank W. Zammetti (MLists) wrote the following on 9/17/2004 2:54 PM: I personally use #3. snip com.company.project | *---actionforms | *---actions | Won't you end up with a TON of Actions though in one package? EmployeeUpdateAction EmployeeDeleteAction EmployeeSearchSetUpAction EmployeeSearchGetAction FooBarInsertAction FooBarDeleteAction I was thinking of breaking it up a bit so all the related Employee actions would be in one package under Action and same thing with FooBar. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: I'm going back to just using regular Actions.. a question
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]
Re: I'm going back to just using regular Actions.. a question
Yes, that's exactly what happens. I understand your approach, even like it! :) I think what it comes down to is do you break things up in an object-oriented way or a functional way? It can be argued that done as you say, you are breaking it up based on objects, which mimics how we generally develop nowadays, so it makes sense. On the other hand, my approach indicates that all the classes in the actions package serve the same general functional purpose. I'm not sure either is more correct in any way than the other... I personally find it easier to work on a project when I don't have to flip between a large number of directories (or, in a related kind of way, a lot of classes). I'm kind of old-school in this regard... The more of a piece of code I have right in front of me in one place, the better. This is largely contrary to OOP ideals, and sometimes I have to fight myself to NOT do what feels natural after so many years :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Fri, September 17, 2004 2:57 pm, Rick Reumann said: Frank W. Zammetti (MLists) wrote the following on 9/17/2004 2:54 PM: I personally use #3. snip com.company.project | *---actionforms | *---actions | Won't you end up with a TON of Actions though in one package? EmployeeUpdateAction EmployeeDeleteAction EmployeeSearchSetUpAction EmployeeSearchGetAction FooBarInsertAction FooBarDeleteAction I was thinking of breaking it up a bit so all the related Employee actions would be in one package under Action and same thing with FooBar. -- 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]
Re: I'm going back to just using regular Actions.. a question
Robert Taylor wrote the following on 9/17/2004 2:58 PM: com.acme.applications.web.foo.account.action com.acme.applications.web.foo.account.service Yea that was my option 2 I posted. I'm still debating about this one as well. I can see both approaches being decent: com.acme.applications.web.foo.account.action com.acme.applications.web.foo.account.form com.acme.applications.web.foo.service.action com.acme.applications.web.foo.service.form OR: com.acme.applications.web.foo.action.account com.acme.applications.web.foo.action.service com.acme.applications.web.foo.form.account com.acme.applications.web.foo.form.service I'm leaning towards the later approach since when I'm looking for something I usually know that I'm looking for a form or an action so I can then look to that top level and go down. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: I'm going back to just using regular Actions.. a question
Yep. I usually bunch all action type stuff in the action package. Like forms, action utils, value objects used in actions, etc... I guess it more or less represents the presentation part of the package and the service represents the business part. I only see a need to dissect it into these two because the actions should only need to talk to the service layer. The service layer should be talking to reusable components in some other package like com.acme.components.whatever. robert -Original Message- From: Rick Reumann [mailto:[EMAIL PROTECTED] Sent: Friday, September 17, 2004 3:05 PM To: Struts Users Mailing List Subject: Re: I'm going back to just using regular Actions.. a question Robert Taylor wrote the following on 9/17/2004 2:58 PM: com.acme.applications.web.foo.account.action com.acme.applications.web.foo.account.service Yea that was my option 2 I posted. I'm still debating about this one as well. I can see both approaches being decent: com.acme.applications.web.foo.account.action com.acme.applications.web.foo.account.form com.acme.applications.web.foo.service.action com.acme.applications.web.foo.service.form OR: com.acme.applications.web.foo.action.account com.acme.applications.web.foo.action.service com.acme.applications.web.foo.form.account com.acme.applications.web.foo.form.service I'm leaning towards the later approach since when I'm looking for something I usually know that I'm looking for a form or an action so I can then look to that top level and go down. -- 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]
Re: I'm going back to just using regular Actions.. a question
We use option one - separate packages for actions, forms, dao, services, util, etc. Rick Reumann [EMAIL PROTECTED] .net To Struts Users Mailing List 09/17/2004 02:41 [EMAIL PROTECTED] PM cc Subject Please respond to I'm going back to just using Struts Users regular Actions.. a question Mailing List [EMAIL PROTECTED] he.org 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]
