struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From wbchm...@Ensign-BickfordInd.com
Subject RE: UML? File organization?
Date Fri, 21 Jun 2002 14:51:41 GMT
Looks like we are in the same boat...

I've done it two different ways so far and I am not sure which way is 
better:

First application

com.ebind.common 
com.ebind.twizard.dao - objects to connect the action to the database
com.ebind.twizard.database - access the database and return recordsets
com.ebind.twizard.reports - the code for the specific action, code to 
support

/web-inf/jsp/common/tiles - generic tiles and layouts
/web-inf/jsp/twizard/reports - jsps (main body only) for displaying 
report action related stuff
/web-inf/jsp/twizard/tiles - tiles specific to this application


In the second application

com.ebind.common
com.ebind.plantsec.create - create.do related code
com.ebind.plantsec.search - search.do related code
com.ebind.plantsec.visitors - business objects for visitors (beans, 
logic, etc)
com.ebind.plantsec.database - database access objects

/web-inf/jsp/common/tiles - generic tiles and layouts
/web-inf/jsp/plantsec/search - jsps (main body only) for displaying 
search action related stuff
/web-inf/jsp/plantsec/create - jsps (main body only) for displaying 
create action related stuff
/web-inf/jsp/plantsec/tiles - tiles specific to this application


So far I am not happy with either of them.  

The only thing I am happy with is the com.ebind.common and 
/web-inf/jsp/common
Since these are all intranet applications, the look and feel is all very 
similar.  With tiles I have a globallayout specified in the common area 
and I just extend and overwrite for a new application.  It takes about 5 
minutes to bring up the look and feel for a new application.  The 
com.ebind.common package is for generic code that will get used across 
all applications possibly.  Both these are maintained seperately and 
pushed down into the applications. 










-----Original Message-----
From: kkamholz [mailto:kkamholz@moog.com]
Sent: Friday, June 21, 2002 10:34 AM
To: struts-user
Subject: RE: UML? File organization?


Hi,
I'm just finishing my first smallish struts app, and the first struts 
app
deployed by the company.  I'ld be interested in hearing your ideas about
package structure.  For now, I just use com.moog.us.beans and
com.moog.us.actions for my Bean and Action classes, respectively.  It 
seems
to facilitate the MVC separation that we all work toward quite well.  I
don't have too many classes right now, so its not a big deal yet.  For
larger applications it could definititely make a difference in headache
severity though.

Keith Kamholz
Moog 
East Aurora, NY
(716) 687-7282
kkamholz@moog.com



-----Original Message-----
From: wbchmura@Ensign-BickfordInd.com
[mailto:wbchmura@Ensign-BickfordInd.com]
Sent: Friday, June 21, 2002 10:34 AM
To: struts-user@jakarta.apache.org
Subject: UML? File organization?



I have been playing with UML and trying to find a good way to do the 
upfront design of a struts based application.  Has anyone done this 
already and have any suggestions?  I know the use-cases can pretty much 
stay the same...

I am also putting together a document on the best way to go about 
struturing your directories under struts...  If anyone has any 
suggestions I would love to hear it...

I already have stuff like JSPs under the WEB-INF and stuff.  I am trying 

to work out the best way to organize all the packages in the src 
directory...  

Should they be by purpose of the objects like (conventional theory)

com.ebind.hrdata.people;
com.ebind.hrdata.companies;
com.ebind.struts.create;
com.ebind.struts.search;


or more along the lines of struts:

com.ebind.peoplefinder.search;
com.ebind.peoplefinder.create;

We've got two small projects done wth struts and the next ones will be 
more complex so I want to get the best practices down (I've printed and 
read the husted site a few times already)


Any thoughts would be great - and I will drop the document out here when 

its done 




--
To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   
<mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: 
<mailto:struts-user-help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message