Not trying to put words in Ted's mouth - I'm sure he'll respond as well.
I think from a pure OO design perspective, the breaking at the level of
billing and reporting are good "chuncks". That is, they are likely high
enough that dependencies between them would be minimal.
Then breaking sub-packages down lower in a consistent way as Ted lays out -
appname.module1.dao
appname.module1.struts
appname.module1.util
The idea here being similar functionality with inter-dependencies being
less important.
While minimizing inter-package dependencies at the lower level may be
harder, it wouldn't be needed as much. Maintanance on "appname.module1.*"
would probably require maintenance on classes in multiple of the
sub-packages - but there would be fewer classes per package and the classes
would be similar in type.
Kevin
[EMAIL PROTECTED] on 06/21/2002 01:13:00 PM
Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
cc: (bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject: RE: UML? File organization?
When you say module1 and module2 below are you inferring something like
billing and reporting (discrete chunks of the application?)
I like this
-----Original Message-----
From: husted [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 21, 2002 12:50 PM
To: struts-user
Subject: Re: UML? File organization?
In general, I'd recommend strongly separating the Struts classes from
the rest of the application.
So, I'd put anything that imports from Struts into a Struts package.
Conceptually, the heirarchy should descibe your application first, and
then show how Struts is used to expose your application to the web tier.
So, I tend to have things like:
[module1 stuff]
appname.module1.dao
appname.module1.struts
appname.module1.util
[module2 stuff]
appname.module2.dao
appname.module2.struts
appname.module2.lucene
[common stuff]
appname.lang
appname.lucene
appnane.struts
appname.sql
appnane.util
If you are writing up practices, I'd start with the recommendation to
first follow the Java package patterns, and treat your application as an
extension of those. So if you are writing collection classes that extend
util classes, they can go into your own util package. Things that extend
Struts can go into a Struts package. Things that extend Lucene can go
into a Lucene package, and so forth.
This follows the general OOP principle that methods that use each other
a lot should be in the same class. Likewise, classes that use each other
a lot should be in the same package.
Generally, I wouldn't do something like have a package for Actions and
another for ActionForms. I'd instead look at which Actions are using
which ActionForms and try to group the packages along those lines.
-T.
[EMAIL PROTECTED] wrote:
>
> I understand what you are saying here. I the example below for the
> packages where would
> (1) something that cleary will be used in many packages go
> (2) something that could be used in another
>
> Would it make sense have both the way shown below and another package
> for business logic
>
> Sooo...
>
> com.ebind.appname.req - (forms, actions, properties files, etc)
> com.ebind.appname.bid
> com.ebind.appname.find
> com.ebind.appname.buy
>
> com.ebind.appname.somecommonfunctions.*
>
> com.ebind.commonstuff1
> com.ebind.commonstuff2
>
> Does that make sense?
>
> Thanks for reminding me about the WEB-INF/JSP issues on other servers.
> I remeber seeing that now
>
> -----Original Message-----
> From: husted [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 21, 2002 11:18 AM
> To: struts-user
> Subject: Re: UML? File organization?
>
> Personaly, I find it most useful to organize everything along
> conventional functional module or package lines. Things that are used
> together should be packaged together.
>
> At some point, these functional divisions might also made into actual
> Struts modules and developed independantly. (This prospect should
figure
> highly in any organizational scheme.)
>
> Within any application, there are tasks that are used together and
tend
> to form subsystems. Often, these tasks are handled by the same
> developer(s) within a larger team, and also tie into the applications
> life-cycle and overall organization. For example, an auction
application
> might have a registeration package, a searching package, a bidding
> package, and a fulfillment package.
>
> For the JSPs, I generally use a /pages folder off the root, and then
> organize by package beneath that. Something like
>
> /pages
> ./reg
> ./bid
> ./find
> ./buy
>
> On the Java source side, there would be corresponding .reg, .bid,
.find,
> and .buy packages
>
> Which I think might all fall under your Conventional Theory category.
>
> I believe this is also the way the Struts source files are organized.
> The Action classes are all kept together, since they all work together
> to form the control layer. Other classes were dispatched to the util
> package (and then off to the commons). The validator has it own
pacakge,
> as does tiles.
>
> We tend to put suffixes like *Action and *Form on classes, but that
> stems from the *Bean naming approach, rather than the package.
>
> Also keep in mind that organizing files for Struts is not any
different
> than organizing them for any Model 2/MVC architecture.
>
> BTW, whether putting pages under is WEB-INF is "best" or not may
depend
> on what container you are using. It is *not* always an option. It also
> means that you might have to separate your JSPs from other assets that
> need to be outside of WEB-INF, like HTML files, images, and
stylesheets.
> Like any strategy, this approach has consequences, both good and bad.
>
> -- Ted Husted, Husted dot Com, Fairport NY US
> -- Java Web Development with Struts
> -- Tel: +1 585 737-3463
> -- Web: http://husted.com/about/services
>
> [EMAIL PROTECTED] wrote:
> >
> > 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:[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]>
