struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Struts directory structure
Date Thu, 01 Aug 2002 14:02:18 GMT

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 []
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 
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
	 - com.explosivo.emp.common.struts.action		(BaseAction
 - com.explosivo.emp.common.logic	

It will be good to have feedbacks from users that used 
and also multiple sub-applications features.
It is important that the structure allow to add these features in the

-----Original Message-----
Sent: 31 July 2002 20:20
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 []
Sent: Wednesday, July 31, 2002 1:12 PM
To: struts-user
Subject: RE: Struts directory structure


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 

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
or com.explosivo.emp.billing.admin.
I don't well understand how the controller / View / Model classes are

>>> 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...


Some classes are common.

-----Original Message-----
Sent: 31 July 2002 16:04
Subject: RE: Struts directory structure

Check out this

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 

Feedback is appreciated...


-----Original Message-----
From: Sandra.Heligon []
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
	The files structure will be placed in the

	Has someone any comment or advice about the following structure:

		- <MyDomain
			- <MyWebApp
				- <Controller

				- <View

				- <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:   
For additional commands, e-mail: 

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:   
For additional commands, e-mail: 

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:   
For additional commands, e-mail: 

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message