No, in our case it's mostly to make the code manageable. We're putting
code into separate packages and separate JSP directories, but it's all
going to be part of the same application in the end. And avoiding
modules wold be nice if possible.

Preston

>>> [EMAIL PROTECTED] 10/11/2005 2:02:48 PM >>>
Some people prefer to stay away from modules (I have a vague memory of
at
least one Struts committer saying they generally try to avoid them for
example).  One option that Craig turned me on to (and I hope I'm
remembering this right!) is using entities to import XML into another. 
If
the only real purpose of using modules is to better organize your
multiple
struts-config files and tiles-defs, this might be a good answer.

<!ENTITY struts_config_2 SYSTEM "config_files/struts_config_2.xml">
...
&struts_config_2;

That, more or less, functions as an import, as I recall (someone
PLEASE
correct me if I got the syntax, or the concept of course, wrong).

Of course, if you have another purpose for modules, like if you have a
desktop CRM application that has a number of largely independent
sub-components (I picked this example because we're discussing this
very
thing right now), then they might be a good fit.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com 
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED] 

On Tue, October 11, 2005 4:36 pm, Preston CRAWFORD said:
> I've done this in the past. Used modules to logically (and for the
sake
> of having sane config files) break up these config files. However
I'm
> wondering if anyone avoids using modules and maybe merges the files
> using ANT or something? Reason I ask is because I know there are
> pitfalls to using modules and I'm not sure I want to have to deal
with
> them for this project (pitfalls like switching between the parent
and
> the module, pathnames, etc.).
>
> Preston
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] 
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] 
For additional commands, e-mail: [EMAIL PROTECTED] 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to