I agree on the internationalization aspects... I am looking into those now and what fun it will bring...
In an earlier draft of the document I had a bunch of illustrations, but as it evolved I took them out until I get to a point where it is somewhat stable. Its an interesting point you have about breaking out the struts directory more. I intentionally avoided all of the that due to arguments over what would go where in the MVC... I am no expert on it at all, so I don't have a big opinion on that part. In my limited experience I think that some of the parts of the MVC in struts blend together somewhat. Like I said I am new to MVC so please nobody crucify me for saying something wrong about it. Can you give me some examples of what would go in each of your struts.model, struts.controller, and struts.view directories? Maybe that would help me see.... All in all, I am really just started trying to get a good best practices document down for internal use, but if I can give it back to the community also then excellent. -----Original Message----- From: Sandra.Heligon [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 4:47 AM To: struts-user Subject: RE: Struts directory structure You don't have to apologize for the errors, I say again it is good to help struts users with a such document. I think that perhaps it will be good to detail the Struts directory structure, perhaps something like this: - com.explosivo.emp.admin.struts - com.explosivo.emp.admin.struts.controller // Action classes - com.explosivo.emp.admin.struts.view // Form classes - com.explosivo.emp.admin.struts.model (only Beans specific to the application would be placed in the Directory but normally the model is independent of the application type. That's why I am not sure that a such directory must exist. Specific application classes will be placed in the com.explosivo.emp.admin.logic directory) My question is where the common struts classes (RequestProcessor subclass, or BaseAction subclass, etc...) must be placed ? Perhaps like this: - com.explosivo.emp.common.servlet (ServletContextListener, HttpSessionListener classes) - com.explosivo.emp.common.struts - com.explosivo.emp.common.struts.controller (RequestPorcessor subclass) - com.explosivo.emp.common.struts.action (BaseAction subclass) - com.explosivo.emp.common.logic It will be good to have feedbacks from users that used internationalisation and also multiple sub-applications features. It is important that the structure allow to add these features in the future. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 31 July 2002 20:20 To: [EMAIL PROTECTED] Subject: RE: Struts directory structure See below for comments... Most of what you picked up are typos and other errors... I will make the changes to the document, but I clarified them below... -----Original Message----- From: Sandra.Heligon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 31, 2002 1:12 PM To: struts-user Subject: RE: Struts directory structure Hi, Your initiative is very very interesting, thanks a lot. I have some questions, sorry if my questions are stupid. I don't understand well the signification of the emp abbreviation. explosivo is used to refer to the global project in which APP101 is the web application, is it true ? It will be good to have a glossary that fix all abbreviations or name (APP101, emp, explosivo etc...). >>> Sorry, emp used to be called APP101 - it was renamed... Its a work in progress. Sorry for the confusion Why do you write /web-inf/src/jsp/emp/html and not /web-inf/src/jsp/html is it in order to introduce multiple sub applications in the future ? In the source code you speak about com.explosivo.emp.admin but in the scheme we see com.explosivo.admin no emp reference. >>>> Again, something screwy in the docs... Should be com.explosivo.emp.admin In the overall structure section you say /web-inf/conf The configuration data is here (validator.xml, *.tld, etc). And in the Utility directories part you speak about /WEB-INF/tld. Always the same question is the project composed of multiple web applications ? and tld of the application (app.tld) will be stored in the web-inf/conf. >>>> Yes, TLD's go into the TLD directory (it was a last minute add on) If I well understand the Struts classes (Action, RequestProcessor, ActionForm, ...) are in the whole project structure under each Struts sub-directory com.explosivo.emp.admin.struts or com.explosivo.emp.billing.admin. I don't well understand how the controller / View / Model classes are organized. >>> Okay, let me see if I can explain this. Mind you that this is not the end all be all of layouts... and your milage will vary. For each logical section of the application we have a directory (admin, billing, etc) Within each we have a few directories named (struts, logic, dao) In the struts directory I have all of my actions, forms, beans that interact with the JSP, etc. I make sure all the code in my actions ONLY deal with preparing data to be handled by the logic of the application or dealing with preparing the resulting data from the logic to be handled by the JSP. The only other thing I will handle in here is dispatching when it cant be handled by struts. In the logic directory is all code that does any thinking. The DAO is supposed to be for database objects, but I extend a BaseSQL class I keep elsewhere so its currently unused. It would be all the code that takes SQL calls handed down from the logic and processes them against the db. Results are returned up to the logic layer. Perhaps an example: I have an app that takes a few selections from a form and based on these selections runs one of four reports and displays them accordingly. * My JSP pages: Takes the data and submits it to the action, using one of the select boxes as the dispatch action * My Struts.ActionForms: Verifys the data to the extent that it is within bounds * My Struts.ActionClasses: Jumps to the correct report routine based on the dispatch and populates a RequestBean with the relevant parts of the request. This is passed to a relevant report in the Logic area * Logic.RedReportLogic: Takes the request bean and gets the data it needs to build the correct SQL statement and query the correct tables. Also handles any sort of decision making about what to do. Passes it down to the baseSQL * Common.BaseSql: Takes the SQL from the logic layer, runs it, returns an Arraylist of dynabeans that make up the resultset. * Logic.RedReportLogic: iterates through the ArrayList, setting and modifying the results as needed to fit the logic (ie: Everywhere the date is before june, change to OVERDUE). Passes this back up * Struts.ActionClass: takes the arraylist, builds some nice descriptive titles, makes a printable version URL and sets the mapping forward based on results. I am really interested in feedback on this writeup... Thanks! Some classes are common. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 31 July 2002 16:04 To: [EMAIL PROTECTED] Subject: RE: Struts directory structure Check out this http://www.explosivo.com/bill/downloads/tomcat The file named struts-directory-layout is a document I have been working on to try to answer this sort of question and to set up some standards internally. Feedback is appreciated... Thanks -----Original Message----- From: Sandra.Heligon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 31, 2002 6:09 AM To: struts-user Subject: Struts directory structure I am trying to organize the Struts files structure for my application. The files structure will be placed in the $CATALINA_HOME\webapps\MyWebApp\WEB-INF\src directory. Has someone any comment or advice about the following structure: <src - <MyDomain - <MyWebApp - <Controller MyRequestProcessor.java MyListener.java <Action - <View <ActionForm - <Model JavaBean sources - <Common The Model directory has only to contain Java sources linked to the web application. The JavaBean classes shared between multiple applications (web or simple Java application) must be placed in an other directory common perhaps ? If someone has other structure proposition, I am very interested. Thanks a lot in advance. -- 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]> -- 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]> -- 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]>
