Division by *usecase* is a very logical one, and we follow that process as well(not 100% though). But the problem with this approach is you cannot reuse one usecase for similar ones easily. You don't want to subclass the originally/written packages since it's already very specific. What we end up doing is copy and paste a whole directory, and do modification from there. It's the worse scenario is software programming, but the fastest nonetheless.
I don't mind a bit of redundancy as you suggested below. But when you have a considerablly-sized project, especially with a lot of files with minor viriation, they add up. It's easy when you work on a project alone, but it gets harder if different people work on different parts and come and go:). -----Original Message----- From: Krishnakumar N [mailto:[EMAIL PROTECTED] Sent: September 9, 2003 2:29 AM To: Struts Users Mailing List Subject: RE: What's a well defined Struts Project Structure? I also follow a similar structure in the project, but I have to say that we have made a mess of it while determining the package structure that now we have 100s of files in a single folder. Ideally, stuff that changes together should stay together; and since most requirement changes are on specific usecases, it would be nice to have the elements that go into the implementation of a single usecase in a single folder. That is, I am considering a structure such as: usecase#1 <e.g., registration> - one or more action classes - one or more action forms - one or more 'system bean's [system beans act as containers for the javabeans generated by the model layer, much like the user containers in the Chuck Cavaness book . We have the habit of putting the model-generated beans into a 'system bean' and putting that into request/session, generally becoz object lifetimes are easier to control and it is easy to see all the information used by, or available to, the views.] - one or more jsps - a few struts config entries - a few tiles definition entries - a few validation.xml entries - a few message resource entries Other stuff, which is mostly common across all usecase implementations (such as images, stylesheets, javascripts, common message resource entries, common struts, validation and tiles entries) should be kept as in the example below. Has anybody managed to partition the presentation layer as above? Some elements (validation, struts-config, tiles) allow multiple configuration files to be specified comma-seperated, which I think should help. From what I know of struts modules, it looks like a overkill for this purpose. Any thoughts? Cheers, Krishna -----Original Message----- From: Matt Raible [mailto:[EMAIL PROTECTED] Sent: Monday, September 08, 2003 10:36 PM To: 'Struts Users Mailing List' Subject: RE: What's a well defined Struts Project Structure? Here's what I do - based on Erik Hatcher's recommendations in his "Java Development with Ant" book: MyProject | - lib (third party jars, etc.) | src (.java files) | test (junit, cactus, webtest tests) | web | images | styles | scripts | WEB-INF | classes | .properties and .xml files web.xml struts-config.xml build.xml For a working example, checkout my appfuse project at: http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuse HTH, Matt -----Original Message----- From: Yansheng Lin [mailto:[EMAIL PROTECTED] Sent: Monday, September 08, 2003 10:37 AM To: 'Struts Users Mailing List' Subject: What's a well defined Struts Project Structure? What a well defined struts project structure would look like? I am always a bit hesitant with where to put things.... Right now, I have: MyProject |- documentation |- images |- jsps |- styles |- javascript |- WEB-INF |- classes |- bin struts-config.xml *.tld project.xml ... But I always run into problems with too many files in one folder or too few files in one folder. I searched the apache CVS tree, and found that it's a mess there too. Just compare Tomcat and Struts, you will know what I am talking about. Thanks! --------------------------------------------------------------------- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
