struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Taylor, Jason" <jtay...@cobaltgroup.com>
Subject RE: multiple sub projects
Date Fri, 27 Sep 2002 16:49:40 GMT
Let's say you have a number of organizations using their own "flavors" of an
application.  You want to allow them to customize whatever features they
want, but you don't want to have more code/JSPs/media than is necessary to
provide the different behavior.  You can think of it as the way
manufacturers maintain different product lines while using the same basic
components, like an auto maker with their different makes and models that
share parts.  

What I'm talking about it is using parallel sub-apps to lift the logic that
dictates what a la carte features each version of the app uses out of code
or JSPs and putting it in struts-config.xml or overridden properties.
Assume we're talking about large clients that make it worth your while to
maintain versions of a product that are arbitrarily different from each
other.  Assume also that you're trying to achieve a level of finality with
released products such that once a stable production release is achieved,
the files that comprise the production codebase is meant to be left totally
unchanged even if the product is enhanced for other clients.

I can say that you can radically reduce the duplication of code/JSPs/media
you use with sub-apps because I've already done it.  From any sub-app I can
call a class or JSP from any other sub-app using a package structure and the
"contextRelative" attribute on the forward.  I can refer to any sub-app's
media from any other sub-app using properties.  If I call one of the
sub-apps "common", you can see an easy way to specify a set of default or
shared code/media/JSPs, which can be overridden on a fine grained level.  By
extending the common Action or form classes to define the "flavor"-specific
ones, I can also use the same pattern of reuse within my code that I'm using
for the app as a whole.  With tiles, you can extend a similar pattern within
your use of JSPs.

Simple version control won't do it, since you'll be in branching hell as
soon as you sign up your second or third customer.  Also, it's better to
have a road map to each version of the application in the config file rather
than scattered throughout a CVS tree in the form of chosen tags and comment
histories.

In any case, you asked for cases where sub-apps are useful, and I've given
you mine.  I may have different needs or considerations than you, and to me
they're useful where they may not be for you.  I'm able to productize my
webapps in a formal way which is both self-documenting and self-policing,
which is better to me than ad hoc decision-making about what client gets
what feature, and worth the added complexity so long as it is stable and
generic.  If this doesn't make sense to you, feel free to ignore the
existence of sub-apps and work with your projects exactly the way you did in
Struts 1.1, just don't expect me to agree that they don't "buy you"
anything.

HTH, 

-JT


> My interest in multiple sub-apps is more related to maintenence and
> post-launch life cycle issues. 
> 
> Modular development is nice, but to me fine-grained control 
> of override
> behavior for every aspect of the deployed application is 
> crucial-- that way
> I can add functionality or upgrade any feature of an 
> application without
> touching any of the original version's code/media/configuration, while
> keeping it all in one deployment unit.

I'm not following you here...do you mean that it's easier because you only
have to upgrade the sub-app for which you are making upgrades?

> 
> This makes it possible to more organically migrate (or 
> rollback) from one
> version to another.  It also reduces the amount of duplicated
> code/JSPs/media/etc drastically when closely similar versions 
> can share
> things.  

Also not following you...how does having multiple sub-apps reduce duplicated
code/JSPs?


> 
> -----Original Message-----
> From: Joe Barefoot [mailto:Joe.Barefoot@motiva.com]
> Sent: Thursday, September 26, 2002 10:20 AM
> To: Struts Users Mailing List
> Subject: RE: multiple sub projects
> 
> 
> Pardon me if this questions seems a bit daft, but what does 
> using multiple
> sub-applications buy you other than splitting the app. into 
> logical chunks,
> each with its own config file?  
> 
> > -----Original Message-----
> > From: Eddie Bush [mailto:ekbush@swbell.net]
> > Sent: Thursday, September 26, 2002 10:23 AM
> > To: Struts Users Mailing List
> > Subject: Re: multiple sub projects
> > 
> > 
> > I believe what you're trying to do is covered by the 
> contextRelative 
> > attribute of the forward.  Have you tried setting 
> > 'contextRelative="true"' on a forward?  What it does is tell Struts 
> > "Interpret this as though it's relative to the APPLICATION 
> > context (not 
> > module context)".  I know this works for global forwards, and 
> > I believe 
> > it would also work for a local one.  Note that by specifying 
> > contextRelative="true" you must provide a path which is, in fact, 
> > relative to the application and not the module :-)
> > 
> > Anthony Martin wrote:
> > 
> > >What about situations where a common .jsp file is used as a 
> > target for
> > >forward by multiple sub-applications?
> > >
> > 
> > -- 
> > Eddie Bush
> > 
> > 
> > 
> > 
> > --
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message